Inferred Parameters

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

You decide if it's a problem or not 😁 . It's something that seems like it could be made better in a bunch of idiomatic use cases.

Declaring parameters comes with a lot of conceptual overhead for the most reductive cases. For instance look at an ARM template like: https://github.com/Azure/bicep/blob/main/docs/examples/101/cosmosdb-webapp/main.bicep#L7

The parameter has to be given a unique name `appServicePlanTier`, has to have a default value, has to specify a range of values. All of this information is separate from the [point of use](https://github.com/Azure/bicep/blob/main/docs/examples/101/cosmosdb-webapp/main.bicep#L64). **Doing a good job** declaring this parameter will duplicate the type and semantic information that bicep **already knows** about the resource its configuring.

For cases where a parameter goes directly into a property of a single resource, it seems like there could be a much terser way of doing this, that surfaces all of the schematized information that bicep already has.

## Describe the solution you'd like

I'd like a way to declare a parameter/placeholder **inline** with its usage, so that bicep can leverage the type information, as well as semantic info like the field description.

I'd also like a way to have these definitions compose with `.`s so that you don't end up with salty names like `appServicePlanTier` and could have something like `farm.sku.name` (based on symbolic + property names). Maybe this should be a separate discussion, but it seems like the ability to have a hierarchy of parameters as `objects` has way less conceptual load than a flat list of parameters. This way a parameterized version of an object roughly follows the definition of a non-parameterized one. This is similar to the approach that's common in helm, where you define parameterizable values as structured objects rather than flat lists.

### Example

From the example here (just grabbing part of it): https://github.com/Azure/bicep/blob/main/docs/examples/101/cosmosdb-webapp/main.bicep

I'm using `?` as the syntax for a placeholder in this example, but I think this part needs a lot more thinking.

Similarly `?` is the syntax for defining a parameter with a non-inferred name.

```
resource website 'Microsoft.Web/sites@2020-06-01' = {
name: ?
location: location
properties: {
serverFarmId: farm.id
siteConfig: {
appSettings: [
{
name: 'CosmosDb:Account'
value: cosmos.properties.documentEndpoint
}
{
name: 'CosmosDb:Key'
value: listKeys(cosmos.id, cosmos.apiVersion).primaryMasterKey
}
{
name: 'CosmosDb:DatabaseName'
value: ?database.name
}
{
name: 'CosmosDb:ContainerName'
value: ?database.container
}
]
}
}
}
```

In this example, this is *as-if* you had declared a parameter called `website` with the schema:

```
{
name: string
database: {
name: string
container: string
}
}
```

The compiler can attach information like types, ranges, and descriptions from the locations where these values are used so that the parameter info for the template is richer.

This is really terse and productive without requiring the author to come up with wierd parameter names, or duplicate information.

Start with docs/examples/101/cosmosdb-webapp/main.bicep, especially the parameter declaration around line 7 and its use around line 64. Compare the current flat parameter approach with the proposed inline and hierarchical examples, then define the syntax, inference rules, and resulting parameter schema before implementation.

Written by the indexing model from the issue text.