OD Process shall support azimuth and elevation data, and JIT filtering of measurement types

[ChristopherRabotin]

High level description

At the moment, OD only support range and Doppler measurement, simultaneous or not. In practice, especially in LEOP, we may want to use azimuth and elevation data to quickly converge on a valid solution.
Moreover, in practice, a tracking data provider may not always align the range, Doppler, and angle data at the same epoch. Hence, this change should ensure that each participant in an ODP can be configured to support either of the supported measurements at runtime without requiring a rebuild.

Requirements

• The ODP must support running with azimuth and elevation data as well. These are currently validated in ANISE, https://docs.rs/anise/latest/anise/almanac/struct.Almanac.html#method.azimuth_elevation_range_sez .
• The ODP must support filtering out this measurement type

Test plans

Simulate tracking data where the range bias is 250 meters for a lunar orbiter. Run the OD in three different cases:

1. Range and Doppler processed at once
2. Range only
3. Doppler only

This will demonstrate just-in-time filtering of measurements, and how processing biased range and Doppler affects the OD results. Use this to write recommendations in the documentation.

Design

This will most likely lead to a decently large refactoring. Specifically, each ground station will need to specify whether it supports a given measurement type. Then, the data read may be nullable (so it must be nullable in the exported data frame). If it's null, or if that participant does not support this measurement type, then the associated row/column of the sensitivity matrix must be nulled as well. This change will likely simplify the trait bounds for the ODP structure, which is why it must be done before version 2.0.0 is stabilized.

[ChristopherRabotin]

Architecture thoughts

• The current structure sets a maximum number of measurements that can be considered simultaneously. This should be kept, but the structs should be differently named, e.g. "ScalarMeasurement" and "Vec2Measurement".
• The sensitivity function should take an input specifying the type of measurements to be used on the next measurement update. This will set the appropriate columns to zero so that the contribution of the innovation is ignored.
• The serialization format is fine.
• Processing of the measurements will be more complicated if several vector dimensions are supported. For example, if the filter is configured to process scalar measurements but there is a range and a Doppler measurement at time t, then the filter shouldn't advance until all measurement types are handled.
• A single measurement might be better represented as a HashMap from an enum to a value? Unsure about this one.

Implementation plan

• Support the new measurement structure in deserialization of a tracking arc
• Support computing the sensitivity for different measurement types based on enum and number of simultaneous measurements
• Replace unwraps with snafu errors
• Build this new measurement structure based on the configuration of each ground station
• Simulator to build this new tracking data arc
• Switch filter to using the new measurement type
• Switch OD to new measurement type
• Update test cases to use either simultaneous Range/Doppler or subsequently
• Add Az/El measurement types