[Task] Extend generic Aspect to AAS conversion to allow more fine-grained customizations

[andreas-schilling]

Is your task related to a problem? Please describe.
The current implementation of the Aspect to AAS converter is a good starting point for simple and quick results starting from an Aspect model (and potentially also Aspect data in form of a JSON payload).
If the main task is to create an AAS representation of a custom Aspect model, this is sufficient as it is. However, for many tasks it is required to be close to an IDTA specified submodel, which has strict specifications about elements like the ShortIds of elements or their Semantic Ids.
This can partially be handled by overriding the Property Mapping mechanism, but it would still not allow doing this for other elements, e.g. SubmodelElementCollection or SubmodelElementList.

Describe the solution you'd like
The conversion setup needs to allow more points where developers can hook in to change the behaviour.
A non-exhaustive list would be:

• Short-Id generation
• Semantic-Id generation
• Creation of each element that can appear in an AAS (e.g. SubmodelElementCollection)

Addditionally, the ESMF-SDK should provide default implementations as a starting point for developers, so that certain standard use cases are already covered (e.g. having a Semantic-Id generator that uses the see element of SAMM properties) and ready to be used.
Ideally, full customization is still only necessary for very special variants of a conversion process.

References
The following issues are related to this topic:

• [Task] CLI aasx Generation - add semanticId to all elements  #522
• [BUG] CLI aasx Generation - semanticId either ExternalREference or ModelReference #523