fix(module-loader) - Fixed ModuleLoader behavior with multiple module catalogs

[lilla28]

Changes:

• picked up changes from branch and commits related to the ModuleLoader when it tries to register its ModuleCatalog 89ec2d9 && 57ad7da
• fixed tests when it registers its modulecatalogs (mocking array of catalogs)

[codecov]

Codecov Report

Attention: Patch coverage is 76.59574% with 11 lines in your changes are missing coverage. Please review.

Project coverage is 74.37%. Comparing base (6262df0) to head (cd3318a).
Report is 1 commits behind head on main.

❗ Current head cd3318a differs from pull request most recent head 7e305ff. Consider uploading reports for the commit 7e305ff to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #569      +/-   ##
==========================================
- Coverage   74.39%   74.37%   -0.03%     
==========================================
  Files         238      241       +3     
  Lines        7351     7391      +40     
  Branches      825      878      +53     
==========================================
+ Hits         5469     5497      +28     
- Misses       1689     1698       +9     
- Partials      193      196       +3     

Files	Coverage Δ
...duleLoader.Abstractions/ModuleNotFoundException.cs	100.00% <100.00%> (ø)
...rganStanley.ComposeUI.ModuleLoader/ModuleLoader.cs	88.00% <100.00%> (-4.00%)	⬇️
...mposeUI.ModuleLoader/Runners/NativeModuleRunner.cs	48.48% <0.00%> (ø)
...y.ComposeUI.ModuleLoader/AggregateModuleCatalog.cs	86.66% <86.66%> (ø)
...ModuleLoader.Abstractions/ModuleLoaderException.cs	25.00% <25.00%> (ø)

... and 1 file with indirect coverage changes

[ZKRobi]

The same id in the same catalog shouldn't ever exist, although it's fine to describe the behavior.
I'd specify what is the first occurance in case of multiple catalogs though -> e.g. in the order of provider registration sounds like a method that is easy to understand, and provides some agency to the developer. This might have implications on how to implement merging modulecatalogs in case of async fetching.

[ZKRobi]

I'd suggest discussing and putting the ADR to Accepted state before merging it together with the PR

[lilla28]

I will create a new commit with the change of the status once everything is resolved and we discussed.

[ztanczos]

Just an idea: what if we'd fail fast & hard if there are duplicates, i.e.: throw an exception and crash? What do you think?

[lilla28]

Yeah we talked about it as well last week we talked about that it would be a kind of a weird thing to throw here an exception so we decided to go with the first item.

[ZKRobi]

To recap, the issue with failing on duplicates from different sources is that it might cause a situation that the developer/user has no way of resolving.
Ideally this is never an issue but if merging multiple module catalogs is a feature we want to support and we wish to keep the standard interface (and not do something like e.g. prefixing ids that would be non-standard), we need a well documented consistent way of resolving these conflicts that the developer/user has a way to control.