Handle transient_local durability when cutting bags

[FranzAlbers]

Messages with transient_local durability are currently dropped like any other message when they had a timestamp outside the cutting period. This can lead to missing static TF-trees (/tf_static) or robot descriptions (/robot_description) in cutted bags.

This PR introduces 'transient_local_policy' as a new argument for cutting rosbags. It has three options:

• 'snap': Sets the timestamp of prior transient_local messages to the start time of the new bag.
• 'keep': Keeps prior transient_local messages with their original timestamp. This might lead to timegaps in the bag.
• 'drop': Drops all prior transient_local messages (current behavior)

Messages after the cutting period are dropped because they should not contain any important data for the new bag anyway.

The default setting is currently 'snap' because this is in my opinion the most intuitive behavior. This is at least well suited for the transient_local durability topics like /tf_static or /robot_description that I currently deal with, as they don't change over time anyway.

Fixes #20.

[devrite]

Thanks. Looks good so far. Maybe it is still better to let the user decide whether to apply it it all transient local topics or just to selected topics. Besides, changing the header stamp, if needed at all, should be optional. Any late subscriber, without cutting the bag, would have perceived the message with it's original content on default.

Just as a note for other readers. Should the use case arise that you have multiple message before the new start time, we will handle this case later, e.g., just keep the last one.

@Kettenhoax Any remarks?