[WIP] Add C Interface to rosbag2

[Martin-Idel-SI]

This is a PR to clarify the C interface for rosbag2. The goal is to allow client libraries for different languages (e.g. rosbag2cpp and rosbag2py) to interact with rosbag2.

I would assume the introduced classes will then constitute the only headers in rosbag2. All other headers will be removed (those are more or less the types I see for rosbag2cpp).

Expected usage:

Record:

• I subscribe to rmw_serialized_message_t * . I initialize a rosbag2_serialized_bag_message_t * and plug in the message handle, timestamp and topic type
• I hand the rosbag2_serialized_bag_message_t * to the storage layer which takes control over it (needs to be documented)
• If the storage layer is finished, it cleans everything up using the message's allocators

Play:

• I initialize a rosbag2_serialized_bag_message_t (in the transport layer) and hand it to the storage layer to be filled.
• I publish the message and afterwards destroy the message (in the transport layer)

Info:

• I initialize a bag handle. I fill it with the directory path and - if I know it - the storage identifier.
• I initialize a bag_metadata struct.
• I hand the bag_metadata to rosbag2, which "actually" initializes it using the information from the yaml file (if available) or reading the storage (only possible if identifier is given).
• I can then do whatever I like with the bag metadata - and when I'm finished, I delete it.

Writer/SequentialReader are used as before. Both contain an opaque struct.

Questions:

• Should these files have ending .h or .hpp? Both are ok with me.
• I separated types, except for the subtypes of bag_metadata - this is something I left in the same file. If you want (or if these types will be used anywhere else), I'd separate them out. Or would you like them to be separated immediately?
• Which types should get an allocator field? Current rationale: I gave all types an allocator that would be processed from outside, i.e. the bag_metadata, the serialized_message, etc, the bag_handle, but not the writer/reader, because those are just wrappers around the true C++ type which allocates its own memory (I think it'll be difficult to work around this).
• What else do we need at this point?

[Martin-Idel-SI]

Currently, we won't spend more time on C-APIs.