Support MCAP as Measurement File format

[KerstinKeller]

Context

Our current hdf5 measurement format has a few drawbacks:

• We don't support compression :(
• HDF5 can be hard to crosscompile
• New bug limit of message descriptor size (Large descriptors cannot be recorded #1062)

The MCAP format is an alternative recording format, designed explicitly for the data recording usecase.

Proposal

Let's support MCAP as a measurement output!

It can be configurable, which file format to write, with the default being HDF5. In the long run, this can be switched to MCAP and at some point (if all goes well) we might deprecate HDF5.

All reading applications (player / meas_cutter / C++ High-Level-API / Python API) should be able to read both formats.

Tasks and updates

• Introduce a common base class with the old eCALMeas interface, so that the alternative implementation can serve as a drop-in (See Measurement: Prepare mcap support by introducing measurement base class. #1077)
• Break up the functionality in Reader and Writer functionality (See Feature/ecal meas reader writer 3 #1078)
• make a Reader class that can read (combined) measurements: Take a look at ecalhdf5 meas dir. Important:
• make an implementation for the base class based on mcap (what about options, etc (-> config items?) and itegrate dependencies via submodules #1092
• Writer integration eCAL Rec: probably need setting on type, communicate via record requests etc
• Writer integration OMeasurement: pass instance to constructer, e.g. let user decide?
• Writer integrationm Meas cutter: Probably need command line argument
• Reiterate on Reader / Writer interface -> AddEntryToFile should take struct. Also maybe reiterate datatypes. (Should be harmonized with EntryInfo. Possibly
• When working on public API, we should consider another point: topic information in monitoring. atm only one info is kept. this leads to heuristics. We should reiterate this!

struct DataEntry
{
  data,
  size,

  topic_name,
  topic_id,

  snd_timestamp,
  rcv_timestamp,
  clock  
}

Todo:

• After Minor refactoring to keep eCAL::hdf5 like it was before hdf5 restructuring #1235, users using the high level measurement api now need to link eCAL::measurement_hdf5 instead of eCAL::hdf5. If we want to keep this compatible, we need to introduce some CMake magic. This has to be discussed.