Rewrite signal module in Rust

[jbangelo]

The second chunk of changes from #122.

This re-implements the GNSS signal related types of functionality in native Rust

What's been changed

• The signal module has been broken up into multiple files, though these extra files are not visible via the public API
• The various string conversion functions have been moved to utilize the derive macros from the strum crate, but the actual string values have remained the same
• Conversions to/from swiftnav-sys integer types has been replaced with conversions to/from native Rust integer types
• The conversion error types have changed to no longer contain the swiftnav-sys types and instead contain native Rust types
• The error types use the thiserror crate to reduce boiler plate code

What's been removed

• Code::sig_count()
• Code::chip_count()
• Code::chip_rate()

What's been added

• The signal::consts module
• Constellation::sat_count()
• Constellation::first_prn()
• Code::get_carrier_frequency()
• Code::get_glo_channel_frequency()
• GnssSignal::carrier_frequency()
• GnssSignal::get_glo_channel_frequency()

[JADC362]

Made a first initial review, will continue later

[JADC362]

Perhaps should we set the 2 and 3 not a magical numbers but with a formal constant name. Could be:

NUM_COMPONENTS_IQ_SIGNAL = 2;
NUM_COMPONENTS_IQX_SIGNAL = 3;

or something like that. It will make it clear the number of components each signal have by setting a name.

[jbangelo]

I'm not sure if that'll really make it any more clear, especially when it's not going to be uniform and not all of the signal naming schemes use I/Q/X

[JADC362]

I've always thought why we don't add somewhere in the documentation of these kind of files from where do we get these constants. It doesn't have to be a really detail reference, but for example at the top of the document put something like:

Information extracted from files:
RTCM version 3.0 ...
BDS reference document...

This way, it's easier for future maintainers to know which files and versions of them have been used to populate all the constants we see here.

[jbangelo]

Basically all of these come from the constellation ICDs I believe

[JADC362]

Perfect! I left some comments mostly related to improve the overall documentation of the modules so it's easy for developers to compile the documentation and easily understand how to use these structs / enums.

[JADC362]

I may not understand the purpose of this module and function. Could you add a module documentation and function documentation for it.

[jbangelo]

I've added a doc comment. Basically we want to find the constellation with the most number of satellites, so we use this here to find the largest value at compile time.

[JADC362]

Could we add a module documentation with a small inline example? The below one is just an example, perhaps the documentation could contain a description of what the module offers and how to interact with it, using the examples as guidance.

//! Signal module
//!
//! This module provides the `GnssSignal`, `Code` and `Constellation` objects, provided with utility functions for easy handling and manipulation.
//!
//! # Example
//!
//! ```rust
//! // Create new GnssSignal
//! let signal = GnssSignal::new(1, Code::Bds3B5x);
//! println!("{}", signal);
//! ```

[jbangelo]

Added some explanation and example code.

[john-michaelburke]

It bothers me that this functionality still has not landed in serde yet as it seems like it would be pretty straightfoward to add and many projects end up using both serde and strum

[john-michaelburke]

Interesting way to avoid lazy execution 😄

[jbangelo]

It seems like const traits are still being worked on so there isn't any generic const comparisons in the standard library. I did find a couple of crates which provide this via proc macros, but this seemed the most straight forward option.