Improve working with featureModules, container configurations

[tortmayr]

Certain aspect of the feature module/container configuration API could be improved

Uniqueness check of featureIds. : FeatureModules operate on the assumption that the featureId of a module is unique among the set of feature modules that should be loaded into the container. Currently we don't check that. In case of duplicated ids, inversify will fail when trying to bind the featureId a second time. However, the resulting error is kind of cryptic and non-intuitive for adopters.
We should implement additional checks both at the end of resolveContainerConfiguration and when trying to load a feature module to catch this problem and throw a better Error.

Issue with replacing a preloaded feature module with a custom variant:
In certain usecases adopters want to full replace one of the default modules with a customized version. Currently this can be done by:

// Reusing the featureId of the module you want to replace for your custom module
const customBoundsModule= new FeatureModule(()=>{//do something}, {featureId: boundsModule.featureId});
and then remove the module you want to replace and add the custom variant instead as part of the container configuration:
configureDiagramContainer(...containerConfiguration,{remove: boundsModule, add: customBoundsModule}; 

This works, but messes up the module order. (bounds module gets removed from its original index location and is added at the end of the resolved module array). Which than has impacts on feature module loading. By affectivly moving the bounds module to the end of the array, loading other featureModules that require the bounds module will fail.

We should introduce a dedicated `replace´ option as part of the container configuration.