Log uncompressed/compressed frames keypoints on disk/RAM

Why this MR ?

When we want to run pose graph optimization, we need to log all extracted keypoints for each LiDAR frame to be able to update SLAM maps after trajectory optimization.

However, these logged pointclouds can become heavy (~2 MB/s on a VLP16). If we want to run SLAM for a long time (several minutes), this can become a limitation as it could saturate the RAM.

Proposed feature

A new class PointCloudStorage is added, allowing to store/restore a pcl::PointCloud<PointT> transparently using different formats for internal pointcloud data storage:

• raw PCL pointcloud (nothing changed from before, stored in RAM)
• octree compression encoding as binary data (stored in RAM, ~5x compression, ~3 ms overhead)
• ascii PCD file (on disk, ~0.6x compression, ~ 5 ms overhead, but in human readable format)
• binary PCD file (on disk, ~1.3x compression, ~no overhead)
• binary compressed PCD file (on disk, ~1.5x compression, ~0.5 ms overhead)

Storage on disk can be useful for debug, allowing to open extracted keypoints clouds. Logged files should automatically be deleted at normal program exit, but could be kept if SLAM crashes and exits unexpectedly (however in this last case, logged files will be deleted on next run, so I don't think we care much).

This logging storage type can be set dynamically in SLAM.

About octree compression

Currently, we use PCL 1.8. Sadly, there is a bug in the octree compression encoding when pointclouds have approximately 2^i points, leading to an integer division by 0 and then to the program termination after raising SIGFPE. This issue was corrected on master branch (see MR).

As long as LidarView is based on PCL 1.8 and ROS depends on this version, we are stuck with this bug. I managed to find a workaround to ignore the few wrongly encoded clouds, but this works only on Linux machines.