Flatten unnecessary nested deployments at build time

**Is your feature request related to a problem? Please describe.**

Due to how modules are authored and consumed in Bicep a parent `main.bicep` file will often consist of multiple module calls which translates to nested deployments in Azure. For simple use cases, this is not an issue, but for larger deployments one can often hit the [800 deployment limit](https://learn.microsoft.com/nb-no/azure/azure-resource-manager/templates/deployment-history-deletions?tabs=azure-powershell) regardless of automatic deletions. Since the automatic deletion is not fast enough, one does not need to have a template that triggers 800 deployments - in many cases a much smaller number is sufficient to get an error during deployment. Additionally, nested modules does complicate resolution for what-if.

Yes, there are many legitimate needs for having nested deployments (cross-scopes, nested loops, etc) but in a lot of cases a deployment is contained to a single scope and _can_ be produced as "flat" single-level deployment. However, authoring files as modules / separate files provides an improved authoring and consumer experience compared to having very large single-file templates - so forcing people to refactor Bicep files due to this limit does not seem as a good solution.

This has especially become an issue after the adoption of using modules from a registry (private or AVM) where one often would like to publish child-modules as consumable modules as well.

The AVM modules have many examples of how a module structure forces a _very_ high number of nested deployments which technically isn't needed for the deployment - see e.g. https://github.com/Azure/bicep-registry-modules/tree/main/avm/res/network/private-dns-zone where pretty much every child-resource is a module call. This is also the recommended AVM approach per https://azure.github.io/Azure-Verified-Modules/spec/BCPRMNFR3/.

**Describe the solution you'd like**
Bicep build should be able to "flatten" nested deployments when the scope of the child-module is the same as the parent module and nested loops or similar does not require a nested deployment. This would reduce the number of nested deployments, in some cases improve what-if quality.

Would also need some method to take into account the template limits https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/best-practices#template-limits when attempting to flatten deployments.

This should probably be experimental and maybe even opt-in - but I think this would improve the deployment experience of Bicep modules.

Start with the Bicep build behavior that emits nested deployments and review how module scope, nested loops, and template limits affect the generated Azure template. Define the cases where same-scope modules can be flattened while preserving required nesting, then verify that deployment limits and what-if behavior remain correct.

Written by the indexing model from the issue text.