Consistency with angular measurements & rotations

[DaveKirkland]

PR #310 brought up an inconsistency between the velocity, rotations and the angular measurements. The convention for this should be standardized and documented.

[DaveKirkland]

So looking at the rotation in the non-linear measurement and rotation, I see a couple of issues:

1. Rotations are only currently only occurring in the non-linear model. I don't see why they couldn't occur in the linear model as well. If that's the case, then there isn't really anything that ties the bearing/elevation orientation to direction of the rotation. Intuitively it makes sense to have a +ve rotation increase an angle in bearing/elevation models, but that could be very different to the intuitive rotations in linear/Cartesian models.
2. I don't think the interaction between platforms, sensors, and measurement models has been well documented.
3. Does the current interaction between platforms, sensors etc. allow for headings that aren't aligned with velocities? As mentioned by David Crouse in #310
4. Handling of multiple coordinates.

I'm not sure if we need to address everything, but at least it should be kept in mind.

[PhilipOakley]

I'd like to highlight that there is no "right answer" to the choice of reference frames and rotation angles. Rather, there are many different standards for the reference frames.

The key issues, from a human error viewpoint is to highlight that there are many different reference systems (with examples) and that users will need to be rather careful of the differences between Stone-Soup's options and their own particular system. It's no good documenting just one choice.

Many major platform systems will have a rather thick tome (e.g. ~80 pages for the early Eurofighter IIRC) detailing all the different reference systems, distortions and offsets (lever-arm) that apply between the different sensors, and that is just for a single platform's attempt at consistency. The rotation discussion also needs to include the alias and alibi distinctions.

My key point is that the documentation should point at the issues/problems, not just the 'solution'.