[Generator][Experimental] Add opt-in dependency-aware sharded Types generation

[jpsim]

Summary

This PR adds an experimental, fully opt-in sharded Types generation mode intended for very large OpenAPI specs.

Default behavior is unchanged. This is an additive path for advanced users who need better generated-code compile times and are willing to adopt custom build integration.

Why experimental

This feature targets a narrow, high-scale use case and introduces additional generation topology (layering + sharding + inter-file imports). Marking it experimental lets us:

• gather real-world feedback before committing to long-term API stability,
• iterate on naming/layout heuristics with lower compatibility pressure,
• keep default maintenance burden low for the core project.

Real-world motivation / observed impact

In our production use case (large spec, filtered subset), generated output compilation was a major bottleneck.
With dependency-aware layering + sharding, we observed >2x faster compilation of generated output.

Example environment and workload:

• OpenAPI source: ~18MB (filtered to ~300 operations for generation)
• Baseline: ~45s generation + ~6m30s release compile of generated output
• Sharded mode: generated output compile time reduced by more than half (roughly ~3m in this workload)

These results are workload- and build-system-dependent, but they motivated proposing this upstream as an optional path for similarly large deployments.

Benchmark snapshot (real-world workload)

The chart below shows compile time of generated output in our production project (not generator runtime), measured on the same filtered spec input.

• Baseline: single-file Types output
• Variant: dependency-aware sharded output
• Observed: ~6m30s -> ~3m (more than 2x faster)

Note: this is one workload and build setup; absolute gains will vary by project and toolchain.

Scope of this PR

• Add ShardingConfig to Config (opt-in only), with validation.
• Add dependency-graph-based partitioning primitives used for sharding.
• Add sharded Types output path (root + component/type/operation shard files).
• Add CLI/config plumbing for explicit opt-in sharding.
• Add tests for algorithms, config validation, and sharded generation behavior.

Non-goals

• No change to default single-file output behavior.
• No auto-sharding heuristics in this PR.
• No promise of stable file naming/layout semantics yet (experimental).

Stability / compatibility

• If sharding is not set, behavior is unchanged.
• Experimental sharded output is explicitly subject to iteration.
• Existing users are unaffected unless they opt in.

Maintenance posture

• Isolated implementation and tests to limit impact on the main generation path.
• Happy to adjust scope, naming, or API shape to align with maintainer preference.
• If preferred, this can be additionally gated/documented under an explicit “Experimental” section.