"Extending" a resource to simplify syntax and support smart defaults

> [!NOTE]
> I'll start by saying this idea has been floated around between a few of us for a while, but I couldn't find a write-up of an existing proposal. If one exists, then feel free to close this one and combine.

> [!WARNING]
> This is currently a work-in-progress

## Problem Statement
One of Bicep's strengths is that the syntax written in a Bicep file is a very close representation of the underlying APIs. This allows us to support new APIs immediately, without requiring any extra work. However, there are some cons with this approach:
1. Design choices that make sense for an API may be less ergonomic or unnecessarily verbose when written in Bicep.
1. Resources can be hard to discover, because the type & api version both must be provided for the mapping to API request.
1. It's hard to know what some of the default values are, so users are torn between providing them explicitly, or expecting the API to pick sensible defaults.

## Modules
Modules arguably solve a lot of these problems, especially the extensive library under https://[github.com/Azure/bicep-registry-modules](https://github.com/Azure/bicep-registry-modules). However, there are still some downsides I think worth discussing:
1. As a module author, you are fully abstracting the API away from the consumer. If a new property is needed, this requires you to publish a new version of your module.
1. There is a performance overhead with using modules, because they result in extra deployments being created. This is something we've been working to optimize, but will still remain non-zero.

## Proposal
Whereas a module is somewhat analogous to the OOP concept of "composition", it feels like there might also be a place in the language for a concept analogous to "inheritance": https://en.wikipedia.org/wiki/Composition_over_inheritance.

### Basic Example
1. Introduce a new means of sharing a partially complete resource - for example:
```bicep
@export()
resource secureStorageAccount 'Microsoft.Compute/virtualMachines@...' abstract = {
properties: {
@overridable(false)
allowSharedKeyAccess: false
@overridable(false)
isLocalUserEnabled: false
@overridable(false)
minimumTlsVersion: 'TLS1_2'
...
}
}
```
1. Usage:
```bicep
import { secureStorageAccount } from 'simplifiedresources.bicep'

resource sa secureStorageAccount = {
name: 'blah'
properties: {
allowSharedKeyAccess: true // raises an error
accessTier: 'Hot' // other properties can be used as usual
}
}
```

Start with the proposal's Basic Example and its comparison with modules. No implementation files or tests are named; a contribution would first need a settled design for exported partial resources, overridable properties, imports, and the resulting diagnostics.

Written by the indexing model from the issue text.