Replace our Kalman Filter implementation by Nyx::KF

[gwbres]

Nyx-Space proposes an advanced and thorough Kalman Filter implementation.
Considering we already use Nyx intensively (and depend on it), it is pointless to rewrite the same functions twice.

The Nyx framework is also more advanced and will most likely perform better. Most notably, with the possibility to upgrade to an Extended KF at the apropriate time.

Current implementation

Our implementation is basic and is the simple KF filter obtained by adding two terms to the LSQ filter.
Our implentation does work and will not change, it will eventually be replaced when this topic is solved.

Vice Versa

On the other hand, we do have a very good LSQ filter implementation.
If it makes sense, it could be cool to introduce LSQ in Nyx along its KF definitions, and remove it from here.

LSQ is sort of a cheap KF, it requires 2 to 4x less operations (roughty), and converges slower.
It does not have the notion of "model" therefore cannot be used to confirm a prediction and improve theoretical models

[gwbres]

Kalman filter is the typical filter you want to use in the navigation process. It is most demanding (2 more terms compared to LSQ) and therefore, most efficient.

Currently, we have a simple form of KF, implemented as ESA GNSS Vol I pages 145 and 146 says. Currently I'm setting Phi (square) matrix as unitary diagonal matrix, which makes the current KF implementation unable to improve itself with real-time evolution of errors. In navigation, we're talking about x, y, z ECEF axis errors, local clock error (dt) and possibly others.
I'm not very familiar with KF yet and need to learn more. This implementation is the only one I understand, because it follows the LSQ filter specs, which are easier and simple recursive filter and the KF is built on top of this very filter. It follows the LSQ notations that ESA has used and is very relatable. It does not seem as the classical KF notations

My strategy to improve the KF filter is simple, and IMO should work.
The improvement should consist in removing this filter and relying on Nyx implementation.
To take that step, we should preserve the current implementation in which we know the Solver works fine, and propose similar function as the PostFit KF that RTKLib implements.

The PostFit KF works on the Solver solutions, the actual results across time and smoothes them.
It is much simpler than the Navigation core KF, for which we need to truly understand the matrix specs.
Therefore is much simple calculation and is the best scenario to become familiar with the Nyx infrastructure.
I already have investigated this topic, but have not spent enough time on it, the code is commented out in Solver, follow the postfit_kf option of the Config structure. Crossing the bridge to Nyx is "simply" to be able to provide the correct Traits and object casts. Which is not simple for that particular topic, yet easier in the case of Post Fit smoothing that navigation calculations.

Note that, truly efficient KF requires knowledge of ongoing std deviation errors. Real-time std deviation evaluation and analysis is easy to do and is closely tied to Ambiguity Solving that phase range navigation demands, because it also requires std dev knowledge (which we do not have yet). So we can either inspire from this core section, or even develop a dedicated deviation analyzer, that all these separate topics can rely upon