[Feature][API Ergonomics]: Add builder pattern for complex constructors

[markusz]

Pre-submission Checklist

• I have searched existing issues to ensure this feature hasn't already been requested
• I have checked the documentation to confirm this feature doesn't already exist

Description

Several types have constructors with many parameters, several of which are Option<T> with None as the overwhelmingly common value. This forces callers to spell out positional None arguments whose meaning is opaque at the call site and makes it easy to pass arguments in the wrong order.

Three prominent exampels are SGPPropagator::from_omm_elements (18 parameters, 9 optional), WalkerConstellationGenerator::new (12 parameters, several almost always zero) and DNumericalOrbitPropagator::new (8 parameters, 4 optional)

Use Case

// Current — caller must know the position and meaning of every None
let prop = DNumericalOrbitPropagator::new(
      epoch,
      state,
      NumericalPropagationConfig::default(),
      ForceModelConfig::leo_default(),
      None,  // params
      None,  // additional_dynamics
      None,  // control_input
      None,  // initial_covariance
)?;

Proposed Solution

Introduce a builder for each affected type. Required fields are passed to builder(); optional fields are set by name and default to None or a sensible value if omitted.

let prop = DNumericalOrbitPropagator::builder(epoch, state, ForceModelConfig::leo_default())
    .propagation_config(NumericalPropagationConfig::high_fidelity())
    .initial_covariance(p0)
    .build()?;

The codebase already uses this pattern in several places (events, trajectories, Jacobian config), so the convention is established.

Impact on Existing API

No impact (new functionality only)

Impact Details

None. Existing constructors remain unchanged; the builder is additive. The clippy::too_many_arguments suppressions on the current constructors can be removed once call sites are migrated.

Contribution

• I can provide test data or validation cases
• I am willing to contribute to the implementation
• I can provide reference material (papers, algorithms, existing implementations)

[duncaneddy]

I like this suggestion for an improvement! Definitely willing to accept a PR for the builder additions. As you mentioned, they exist in places but can definitely get built out further.

I'm a little hesitant to fully deprecate the existing ::new() constructors with all arguments given that's a little user-space breaking, and I think the addition of a ::builder() chained convention suits both needs. So I'm all for standardizing on that dual-approach.