Using `deployment().name` with Deployment Stacks in large deployments increases chances of hitting 800 deployments at a scope limit

## Current Issue
The deployment stack generates a **new, unique deployment name** every time it is created or updated (via `new-...` or `set-...`). When we use the `deployment().name` function in our templates to create unique, but deterministic deployment names, this behaviour causes problems:

- Each update to the same stack changes creates a new deployment name.
- Because the input changes, our templates also generate new deployment names as we use `deployment().name`
- This results in many unique deployments being created unnecessarily, which accelerates hitting the **800-deployment limit**.

### Why It Happens
- The stack’s deployment name naming mechanism is non-deterministic (always unique).
- Our templates rely on `deployment().name`, so any change in the stack name cascades into new names for our deployments

### What else this impacts
- The optional Module Name feature released in version `0.34.x` in bicep also uses the `deployment().name` function so this is also a victim of this issue in larger deployments

## Suggestions
- Implement a flag to keep the deployment name that gets created by the deployment stack the same in the deployment stacks resource
- or implement a property to allow a deployment name to be set by a user for the deployment stacks "proxy" deployments
- Remove or increase the 800 deployment limit
- Resolve the issue with the time taken for the 800 limit auto clean-up to take place as can take significant times and often we just end up doing it manually and building our own retry logic as its not reliable today 😢

cc: @majastrz (optional module name feature awareness), @azcloudfarmer (deployment stacks)

## Example/Repro

The above screenshot shows this behaviour. These are the resulting deployments from a single bicep template and single deployment stack that was created and then updated with no changes to force a redeploy.

The blue box is the first deployment stack creation with the bottom deployment being the deployment stack created deployment name. The red box is the deployment stacks 2nd set of deployments, with the bottom one being its new/different created deployment name 😢

### Templates

`main.bicep`

```bicep
targetScope = 'managementGroup'

@description('How many times to loop.')
param loopCount int = 5

@description('The name of the management group to create or update.')
param managementGroupName string = 'wait'

@description('The location to deploy resources to.')
param location string = 'uksouth'

var deploymentNameIndexSuffixReserve = 4
var deploymentNameBaseMax = 64 - deploymentNameIndexSuffixReserve

var deploymentNames = {
looper: take(
'${uniqueString(deployment().name, location)}-loop-${managementGroupName}',
deploymentNameBaseMax
)
}

@batchSize(1)
module looper 'modules/loop.bicep' = [
for (item, index) in range(0, loopCount): if (loopCount > 0) {
name: '${deploymentNames.looper}-${index}'
}
]
```

`modules/loop.bicep`

```bicep
metadata name = 'looper'
metadata description = 'looper'

targetScope = 'managementGroup'
```

Start with the provided main.bicep repro and modules/loop.bicep, then inspect how deployment().name is generated for deployment stacks. Reproduce repeated stack updates and compare the resulting deployment names and counts. Done should be a confirmed approach and tests showing that repeated updates do not unnecessarily create unique deployments or that the stated limit and cleanup behavior is addressed.

Written by the indexing model from the issue text.