Nested deployment stacks

**Is your feature request related to a problem? Please describe.**
We are using deployment stacks in a multi subscription environment (high number) in a Landingzone context.
To protect our resources related deletion/changes we use `deny-settings` which just works fine in most cases.
So our resources are protected.
Because of our subscription RBAC model we have some people within a subscription able to change deployment stacks on subscription level. (We cannot change the RBAC model because those people should also be able to use deployment stacks within their subscription.)
To be able to protect our deployment stacks we deploy them at management group level with the underlying deployment subscription. This is working fine for now.
⚠️ Unfortunately there is a limit of 800 deployment stacks per management group which limits us to structure our stacks in a convenient way. We need to deploy stacks which contain many resources (taking a while to deploy and we run into throttling issues and other complications).
Furthermore we have many subscriptions and we will run soon into the 800 limit (already having a structured management group tree).

**Describe the solution you'd like**
One idea to solve this issue would be to have a deployment stack containing other deployment stacks (so a bicep template for deployment stacks). The first one we will deploy at management group scope with `deny-settings`. The containing deployment stacks we deploy at subscription level. We could even put more than one subscription into the parent deployment stack. Important would be to be able to update just one child (e.g. with parameters). That way we are able to protect the deployment stacks on subscription level.

```mermaid
---
title: Idea Stack overview
---
flowchart LR
parent["Management group level
containing the parent stack ⬆️
deny settings enabled
"]

child1["subscription level
containing the first child stack 🧒
"]

child2["subscription level
containing the second child stack 🧒
"]

parent --> child1
parent --> child2
```

One could also think about the possibility to deploy stacks at a management group level to child management groups to subscriptions

**Describe alternatives you've considered**
We considered to deploy the deployment stacks at subscription level and protect them by changing the RBAC model and with policies. But unfortunately Policies are not super powerful in that matter and we don't want to disable the other users using deployment stacks.

Start by reviewing the repository's deployment stack CLI scripts and the Azure management-group and subscription deployment behavior described in the issue. Determine how parent and child stacks, cross-scope deployment, deny-settings, and updates to a single child would need to work; done means the design and supported behavior are defined, with validation for the stated limits and permissions.

Written by the indexing model from the issue text.