Add Multi-Measurement support in a single vertex

[planthaber]

This basically adds optional sub-Measurements to VertexObjects and allows to use tags on them, without changing interfaces to slam3d.

This also removes forced graph->optimize() on loading a graph from hdd (so it does not change locations from those loaded from hdd)

Mainly added a std::vector subMeasurements; to a VertexObject allowing sub- measurements with sensor location.

VertexMeasurementData is a new Type containing the sensor data, but VertexObject inherits from it, leaving the interface intact.

Tags are stored in the VertexMeasurementData type, so the VertexOject and submeasurements can be tagged differerently.

A new sensor/pcl/MultiPointCloud sensor is added, which utilizes the new structures and tags.

This newly added structures allow multiple use-cases for slam3d users:

• Store data from multiple laserscanners in subMeasurements and have a combined cloud as main measurement
• Store segmented (and possibly labeled) sub-clouds: "surface", "obstacle"
• Map creation can be done on selected sub-Mresurement clouds e.g. just obstacles. (compared to using multiple vertexObjetcs, the relative positions are fixerd and can't be changed by optimization)
• Store deleted points ins a sub measurement to keep them (optionally) available
• Add non-slam data to vertices (like pictures, environment data (temperature, humidity, etc.))

[skasperski]

After having a closer look, I have to say that I am against merging this.

• The VertexObject inheriting VertexMeasurementData and also having a vector of those is a questionable design choice.
• The MultiPointcloudSensor duplicates almost all of PointcloudSensor. What was the reason not to inherit from it instead?

[skasperski]

In general, I see three ways to implement this feature:

1. Create a vertex for each sub-measurement

• Connect any type of measurement
• Usable for other sensors
• Maybe add a new rigid identity edge-type to connect sub measurements

2. VertexObject holds a vector<UUID> instead of just an UUID

• Connect any type of measurement
• Usable for other sensors
• Each sensor must check for multiple measurements

3. New measurement type MultiPointcloudMeasurement and sensor

• No change in core
• Flexibility in how to handle different sub-clouds
• Sub-measurements can be measurements as well and put into storage

I have a light tendency towards 3, as it seems the nearest to what was done in this PR.

[planthaber]

1. With multiple VertexObjects, die optimizer has more to do and can change internal transforms.
2. This is basically what this PR is with the addition that meta-infromation of the measurement is part of the (sub-) VertexObjects
3. When the information is only in the measuremnt we need to get and desieialize the measurement itself in the database case, I'd prefer filtering ob the vertexObject themselfes