Proposal - simplifying resource referencing (part 2)

# Proposal - simplifying `resource` referencing (part 2)
[Part 1](https://github.com/Azure/bicep/issues/2245) / [Part 2](https://github.com/Azure/bicep/issues/2246)

## Problem statement
Passing around / obtaining references to resources in a type-safe manner is overly complex. Rather than inventing non-type-safe mechanisms to refer to resources or resource properties, we should provide a first-class syntax for doing so, with full type-safety and editor support.

## Resources as params and outputs
A new type of `resource` will be accepted in `param` and `output` declarations to permit passing a reference to a resource as an input or output for a module. Supplying the type string for the resource would be optional, but functionality would be greatly reduced without it.

At compile-time, Bicep will type check for reference equality - it will ensure a valid resource reference is passed to a generic resource param, and it will ensure that a valid resource reference matching the expected type string is passed to a typed resource param.

### Examples
#### Generic
```bicep
// we haven't specified a resource type here
param lockableResource resource

resource lockResource 'Microsoft.Authorization/locks@2016-09-01' = {
scope: lockableResource
name: 'DontDelete'
...
}
```

#### Input/Output
```bicep
// input a resource reference
param storageAcc resource 'Microsoft.Storage/storageAccounts@2021-01-01'

var myContainer = storageAcc.child('blobServices', 'default').child('containers', 'myContainer')

// output a resource reference - note the resource type can be omitted
output myContainer resource = myContainer
```

#### Property access
```bicep
param storageAcc resource 'Microsoft.Storage/storageAccounts@2021-01-01'

// list keys
var myKey = listKeys(storageAcc.id, storageAcc.apiVersion).keys[0].value

// property access
output accountTags object = storageAcc.tags
```

### Notes
1. If the param does not specify a resource type string, functionality will be greatly reduced - limited to using the resource as a scope for an extension resource, and accessing the resource `id` property. We want to encourage module authors to be specific about the type they accept to provide optimal type safety.
1. API versions do not need to match across module params and outputs, but types must match if the param has specified a type.
1. We will need to be careful when passing param references to resources at a different scope to the module, as they cannot be used for certain purposes (deploying children/extensions, for example).

### Out of scope
1. This proposal requires both inputs and outputs to accept a resource reference, and there is no conversion between resourceId string and resource reference. The following would not be permitted:
```bicep
module myMod './module.bicep' = {
name: 'myMod'
params: {
// resourceReference is a param of type 'resource'
// resourceId is a string containing a resourceId
resourceReference: resourceId
}
}
```

### Codegen
The most straightforward option for JSON codegen is to generate a string parameter or output in the template JSON, with some associated metadata.

Read the linked Part 1 issue alongside the resource parameter/output examples and the Codegen section here. Trace the existing handling of resource references, module parameters and outputs, type checking, editor support, and JSON generation; done means the proposed syntax and type safety work consistently for the described generic, typed, property-access, and codegen cases.

Written by the indexing model from the issue text.