UserAccess module based on Microsoft Identity (second edition)

[jfstirn]

🧩 Summary
This PR refactors the UserAccess module to introduce a second implementation based on Microsoft Identity, improve module isolation, and streamline module initialization within the host application.

🚀 Key Changes

• Added a second UserAccess module based on Microsoft Identity.
• Introduced a dedicated WebAPI project inside the original UserAccess (IdentityServer) module to move controllers out of the Host API.
• Moved module initialization logic from the Host API into the module’s infrastructure assembly.
• Implemented module loading via ModuleLoader (BuildingBlocks.Infrastructure.ModuleHosting) in the application startup.
• Added UserAccessModuleSelector to configure and start either the IdentityServer or Microsoft Identity module via configuration.

🧠 Rationale
These changes improve modularity, decouple user access responsibilities from the Host API, and allow selecting between identity providers (IdentityServer or Microsoft Identity) through configuration.

Architectural Note
The new Microsoft Identity–based module differs from existing modules in that it relies on Result-based communication between layers rather than exception handling.

• The Web API sends a command or query to the Application layer.
• The Application returns a Result (e.g., Result.Ok, Result.Created, Result.Forbidden, ...) instead of throwing exceptions.
• The Web API then converts this Result to an Http.IResult and sends the response to the client.

✅ Next Steps / Notes

• Verify Database scripts.
• Extend the Nuke build to include tests for the Microsoft Identity UserAccess module.
• Consider removing the SDK and Contracts projects.
  • The Contracts project was originally added to demonstrate how to implement an Anti-Corruption Layer (ACL), avoiding direct exposure of DTOs from the Application layer.
• Feedback and suggestions are welcome — let me know what you think.