Change userAssignedIdentities from object to array

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

I have an AKS cluster that I want to have a user assigned identity. This user assigned identity is created using a helper module for creating managed identities. The problem is, that assigning the output id from this module to the `userAssignedIdentities` in `identity` causes bicep to issue the BCP120 error since it is an object where the key is the identity id rather than an array of objects (where the id could be a property), so it is simply not possible to use the output from my managed identity module as the value during AKS creation.

**Example:**

_managedidentity.bicep_
```
@description('The name of the managed identity to create.')
param name string

@description('The location of the managed identity')
param location string

resource mi 'Microsoft.ManagedIdentity/userAssignedIdentities@2018-11-30' = {
name: name
location: location
}

// Some more code here that does role assignments and so on

output id string = mi.id
```

_aks.bicep_
```

var idName = 'id-aks-${environment}-${location}'

module aksidentity 'managedidentity.bicep' = {
name: 'aksidentity'
params: {
name: idName
location: location
}
}

resource aks 'Microsoft.ContainerService/managedClusters@2022-07-02-preview' = {
name: 'aks-${environment}-${location}'
location: location
sku: {
name: 'Basic'
tier: 'Free'
}
identity: {
type: 'UserAssigned'
userAssignedIdentities: {
'${aksidentity.outputs.id}': {} // this gives me BCP120
}
}
// more configuration here
}
```

The line that has the comment `// this gives me BCP120` gives this complete error:

> This expression is being used in an assignment to the "identity" property of the "Microsoft.ContainerService/managedClusters" type, which requires a value that can be calculated at the start of the deployment. Properties of aksidentity which can be calculated at the start include "name". bicep(BCP120)

While I can see the reason for this to happen it is very unfortunate that it isn't possible. I have found a couple of workarounds, but I think those makes the code a bit clumsy to work with, so an alternate solution would be nice to have.

One workaround I have found (and uses) is simply to use `'${resourceGroup().id}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/${idName}': {}` and it will work but it doesn't look smooth.

**Describe the solution you'd like**

I would like the `userAssignedIdentities` to be like other properties that takes multiple values; an array of objects. This will make it possible to have dynamic values and in addition is a smoother way and more consisting way to do it compared to other properties that works with arrays/collections. It will also be more future proof if neccessary.

Example:
```
resource aks 'Microsoft.ContainerService/managedClusters@2022-07-02-preview' = {
name: 'aks-${environment}-${location}'
location: location
sku: {
name: 'Basic'
tier: 'Free'
}
identity: {
type: 'UserAssigned'
userAssignedIdentities: [
{
id: '${aksidentity.outputs.id}'
properties: {} // if any and needed
}
]
}
// more configuration here
}
```

I can see that this may break with the ARM template way since that uses the same way as bicep today, but it should either be fixed in the ARM as well or mapped from array -> object in the bicep to arm transformation somehow.

Start by tracing how the identity property produces BCP120 and how Bicep maps it to ARM templates, using the managedidentity.bicep and aks.bicep examples as the expected scenario. Done means a user-assigned identity can be supplied from the module output in the requested array form, with the resulting ARM representation remaining correct.

Written by the indexing model from the issue text.