adot and n0dot in civilian GNSS messages should have associated parameter drivers

The propagation parameters in GNSSOrbitalElements are driven by ParameterDriver instances except for aDot and deltaN0Dot, which have been introduced in the new civilian messages (GPS, QZSS, NavIC and Beidou). For non-civilian messages, the base implementations of getADot and getDeltaN0Dot getters in GNSSOrbitalElements return hard-coded 0.0 values, so the legacy GNSS propagation algorithms work. These methods are overridden in CivilianNavigationMessage (for GPS, QZSS, NavIC) and in BeidouCivilianNavigationMessage (for Beidou), where they return mutable values. There are simple setters in these classes too.

This design prevents estimating these two parameters using for example a batch least squares, which requires using ParameterDriver instances.

The adot and n0dot parameters should be implemented as ParameterDriver just as all the other parameters. A new isCivilianMessage() predicate should be added that would return false at GNSSOrbitalElements level and be overridden to return true in CivilianNavigationMessage and BeidouCivilianNavigationMessage.