"existing" functionality for modules

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

We have a Bicep module registry which we use to wrap Bicep templates, such that they are delivered to match our organisations collectively agreed security posture. So to create a storage account we'd do something like this:

```bicep
module deadLetterStorageAccount 'br:icebox.azurecr.io/bicep/ice/providers/storage/storage-accounts:v1.0' = {
name: 'lens-dead-letter-storage-account-${branchHash}'
params: {
tags: tags
location: location
storageAccountName: opticalDeadLetterStorageAccountName
skuName: 'Standard_ZRS'
}
}
```

If we want to reference the resource created by that module later elsewhere, we can do that using `existing` like so:

```bicep
resource opticalDeadLetterStorageAccount 'Microsoft.Storage/storageAccounts@2021-02-01' existing = {
name: opticalDeadLetterStorageAccountName
scope: resourceGroup(opticalStorageResourceGroupName)
}
```

But this is not a great developer experience as:
1. We have flipped from `module` syntax to `resource` syntax which is confusing
2. We have to go and look up what resource is used in the module to be able to write the module statement
3. If that module is updated to use a different resource, we have to find out the new one and then copy/pasta that across all our `resource ... existing` references

**Describe the solution you'd like**

What would be delightful is if there was some kind of `existing` syntax for modules. Imagine if, instead of:

```bicep
resource opticalDeadLetterStorageAccount 'Microsoft.Storage/storageAccounts@2021-02-01' existing = {
name: opticalDeadLetterStorageAccountName
scope: resourceGroup(opticalStorageResourceGroupName)
}
```

we could do:

```bicep
module deadLetterStorageAccount 'br:icebox.azurecr.io/bicep/ice/providers/storage/storage-accounts:v1.0' existing = {
name: 'lens-dead-letter-storage-account-${branchHash}'
params: {
tags: tags
location: location
storageAccountName: opticalDeadLetterStorageAccountName
skuName: 'Standard_ZRS'
}
}
```

This would make upgrades much more straightforward / intuitive.

There's obviously a whole bunch of complexity in what I'm suggesting - but something like this would be amazing. Something that allows you to acquire the resources created by a module directly rather than indirectly. What do you think?

The issue names no implementation files, tests, or entry points. Start by tracing how Bicep parses and validates module declarations versus existing resources, then determine how module outputs and resource acquisition should behave; done means an agreed design and corresponding coverage for the proposed existing-module syntax.

Written by the indexing model from the issue text.