Syntax ideas for supporting extension resources with lexical nesting

^{Originally posted by **anthony-c-martin** February 17, 2021}
# Syntax ideas for supporting extension resources with lexical nesting

This is an open discussion thread to come up with a syntax for declaring extension resources in a manner compatible with #1363. To get started, here are the options I see:

## 1. Try to infer it
### a) Use the fact that the fully-qualified type must be supplied
```bicep
resource myParent 'My.Rp/parent@2020-01-01' = {
name: ...

// this is an extension resource (type contains a single '/' character)
resource myExtension 'My.OtherRp/extension@2020-01-01' = {
name: ...
}

// this is a child resource (type does not contain any '/' characters)
resource myChild 'child@2020-01-01' = {
name: ...
}
}
```
* Pros
* Simple and ties in with the child resource declaration.
* No special syntax required to declare an extension resource.
* Cons
* Subtle, possible to introduce accidental bugs.
* Doesn't map cleanly to the proposed 'parent' syntax for refactoring.
* Intellisense for child resource types won't be as clean as it'll have to also show all possible extension resources.

### b) Use a list of known extension types to understand whether or not the provided type string is an extension resource
Not considered - this removes the 'day 0 resource support' promise.

## 2. Some indicator of intent in the language or type string
### a) Keyword
```bicep
resource myParent 'My.Rp/parent@2020-01-01' = {
name: ...

// 'extension' keyword
resource myExtension 'My.OtherRp/extension@2020-01-01' extension = {
name: ...
}
}
```

### b) Prefix in the type string
```bicep
resource myParent 'My.Rp/parent@2020-01-01' = {
name: ...

// prefix for the type string (option i)
resource myExtension 'ext://My.OtherRp/extension@2020-01-01' = {
name: ...
}

// prefix for the type string (option ii)
resource myExtension '/My.OtherRp/extension@2020-01-01' = {
name: ...
}

// option iii - some other prefix (not shown)
}
```

* Pros
* Author's intent is clear and unambiguous.
* Intellisense should be able to help with suggestions.
* Clear mapping to/from the 'scope' property.
* Cons
* Doesn't feel very natural, will probably require looking up the syntax each time.

## Current state of the 'top-level' extension/child syntax (for reference)
```bicep
resource myParent 'My.Rp/parent@2020-01-01' = {
name: ...
}

// Extension resource
// NOTE - the type string for the resource being extended is not present in this declaration
// NOTE - there's also a potential proposal to rename 'scope' => 'extends'
resource myExtension 'My.OtherRp/extension@2020-01-01' = {
name: ...
// declare the resource that this one is extending
scope: myParent
}

// Child resource
// NOTE - the type string is the fully-qualified type string instead of just 'child'. This is to permit intellisense before the 'parent' property has been entered.
resource myChild 'My.Rp/parent/child@2020-01-01' = {
name: ...
// declare the resource that this one is a child of
parent: myParent
}
```

### Notes
If picking option 1, it feels like it would make sense to come up with a consistent mapping between the 'top-level' syntax and the 'nested' syntax which combines both the 'parent' & 'scope' property into one.