[Rock-dev] Revisiting the sonar data structures

[Sylvain Joyeux]

Since we're (at BIR) are getting very much in sonar processing, we
thought it would be good to revisit the sonar data structures

The goal would be to have a single data structure for both multibeam
and mechanical scanning sonars, and to fix the quirks of the current
data structures, which are mostly, out of the top of my head:
 - unnormalized bin values (one byte is not enough to pre-normalize
the data in case of high gains)
 - weird optional layout (for multibeam)

I personally was very optionated against reusing one of the
laserscan-class types, as sonar data is very different than laserscan
data (one is mostly echo-range plus optionally remission the other is
only about remission, and one is mostly single-echo and the other is
multi-echo by nature).

Nonetheless, since Sascha went already through the pain of getting a
clean DepthMap type, and because I remembered that DepthMap has a
feature set close to the ones a sonar type would need, I went through
it. There's a lot of commonality which leads to two strategies:

 - reuse the DepthMap type (extending it through subclassing to add
metadata specific to sonars such as beam shape parameters). It would
look a bit awkward: there's no "depth measurement state" for sonars,
and there are no echo distances (data would be in 'remission' instead
of in 'distances'). 'Vertical' would mean 'Depth'. The current
non-data API related to state and conversions to pointclouds would be
meaningless (would even crash since there are no distances).

 - create a separate type, but heavily inspired from DepthMap

Sylvain