Expose ConfigRepr capabilities in Nyx Python API

[ChristopherRabotin]

High level description

After utilizing the Nyx toolkit in Python, stakeholders have identified additional functionality needed in the Python interface to improve usability.

Specifically, users need the ability to:

• Initialize Nyx objects like OrbitTraj directly from Python dictionaries, for easy creation from existing data.

• Serialize Nyx objects to pickle format in Python for convenient saving and loading.

• Deserialize pickled Nyx objects back into native Python objects.

These capabilities will allow seamless interoperability between Nyx objects and common Python workflows like loading simulation data or persisting objects to disk.

Enabling dictionary initialization and pickling will provide more flexibility when interacting with Nyx from Python code. This will improve developer experience and productivity.

Let me know if you would like me to modify or expand this high-level description of the stakeholder needs in any way. I'm happy to clarify or add further details as needed.

Requirements

Any Nyx object implementing the Rust ConfigRepr trait must also expose equivalent functionality to Python

This includes:

• Initialization from a Python dictionary
• Conversion to a Python dictionary representation
• Pickling/unpickling to/from Python bytes
• The specific Nyx objects requiring this will be determined separately
• Pickling logic must handle any nested Nyx objects properly, i.e. call load named or load many just load depending
• Expand Python unit tests to validate:
  • Dictionary initialization matches direct constructor
  • Pickled object matches original when unpickled
  • Nested objects are preserved in dict and pickling
• Pickling implementation will leverage Python's pickle module
• No changes needed to core Rust crate implementations

Design

No change to design.

Affected classes:

• Ground Stations
• Spacecraft
• Spacecraft Dynamics to support serialization and pickle #214
• OrbitEstimateSerde to support pickle #215
• GaussMarkov
• FltResid
• TrkConfig

[ChristopherRabotin]

We cannot pickle GaussMarkov because it includes hifitime Duration which is of type builtin.Duration and I can't change that.

[ChristopherRabotin]

Upon further consideration, I think that the loading should not be clever from the Python side: data should be pickled and unpickled and always expect and return a single object. The separation of dictionaries can be done on the Python side if needed. Cleverness often leads to poor design choices, and in this case, it requires the loading to return a vector of Self even if it's loaded from a dictionary: this is a bad design choice.

[ChristopherRabotin]

Done in #216 , with the follow-ups identified above.