Enable incremental submodel composition via .AddSubmodel() at any stage of the build process

[Freezor]

Is your feature request related to a problem? Please describe.
Currently, submodels must be composed inline within a single fluent builder chain. While this works well for small models, it becomes limiting in larger or modularized scenarios.

I often need to construct parts of a submodel in different locations (e.g., different services, modules, or layers) and add them later in time. At the moment, this requires composing a long fluent statement or restructuring code in ways that reduce readability and modularity.

This becomes especially problematic in:

Larger domain-driven designs

Plugin-like architectures

Stepwise model enrichment scenarios

Late-binding or staged assembly pipelines

The current fluent DSL encourages linear construction, but not incremental composition.

Describe the solution you'd like
Introduce a .AddSubmodel() method that allows submodels (or submodel fragments) to be added at any stage of the builder lifecycle.

Desired behavior:

var aasBuilder = AasBuilder.Create("urn:aas:id:123")
    .WithAsset("urn:asset:id:xyz", AssetKind.Instance);

// Later in the code (possibly another module)
aasBuilder.AddSubmodel(submodelPartA);

// Even later
aasBuilder.AddSubmodel(submodelPartB);

// Finally
var aas = aasBuilder.Build();

Potential design considerations:

• Allow multiple .AddSubmodel() calls before .Build()
• Ensure immutability of the final model (Core remains unchanged)
• Preserve inline validation guarantees
• Maintain compatibility with existing fluent chaining

Optional extension:
Allow partial submodel builders to merge into an existing submodel by ID.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context

1. Building full submodels externally and injecting them once → Works, but prevents staged enrichment and modular extension.
2. Creating a custom aggregation wrapper outside the library → Adds unnecessary complexity and duplicates builder responsibility.
3. Maintaining one large fluent chain → Reduces readability and breaks separation of concerns in larger systems.

None of these options fully align with the modular architecture goals described in the documentation