Binary encoding of radar/lidar data on reflection/detection level

[PhRosenberger]

As discussed several times, we should consider investigating possible ways to binary encode radar/lidar data at the reflection/detection level.

This is seen as a possible way to reduce the amount of data to be transmitted and improve the performance of the simulation.
Some partners, such as aimotive, have already mentioned problems when simulating multiple sensors in a co-simulation, as the ReflectionData / DetectionData simply becomes too large for this use case.

Also, the Persival report on the possible switch to flatbuffers in March 2022 already mentions the binary encoding option:

After all application and performance evaluation of Flatbuffers against Protobuf, we as the service
provider for this first trial would not recommend to switch to Flatbuffers. Possibly other data encoding for
lidar/radar reflections/detections that e.g. uses some regular binary scheme in the first place, as it is
already the case for camera data, seems to be more promising regarding data amount and
serialization/deserialization time for now. Such data encoding would bring the possibility of applying data
reduction and does not need a deserialization step, as is the case with Flatbuffers. If lidar/radar binary
encoding would be added to OSI as just another field, this would keep backward compatibility and would
not bring the overhead of the Flatbuffers application that is “definitely not the simple implementation
solution to all performance problems that it was promised to be”, as already summarized at the end of
the application report.

So let's discuss and collect ideas here!

[PhRosenberger]

@ClemensLinnhoff @pmai @jasonxzzhang

[PhRosenberger]

Already tackled by #764. So I close this one.