Solving BCP178 with "inline" modules

**Is your feature request related to a problem? Please describe.**
One of the problems that I was hoping that Bicep would solve more cleanly for me is the need to create a parent dnsZone and a child dnsZone and create the NS delegation records in the parent zone. Here is my Bicep file where I attempt to do this:

```bicep
param baseDomainName string = 'parent'
param location string = resourceGroup().location

resource parentDomain 'Microsoft.Network/dnsZones@2018-05-01' = {
name: '${baseDomainName}-domain.io'
location: location
}

resource childDomain 'Microsoft.Network/dnsZones@2018-05-01' = {
name: 'child.${baseDomainName}-domain.io'
location: location
}

resource childDomainDelegation 'Microsoft.Network/dnsZones/NS@2018-05-01' = {
name: '${baseDomainName}-domain.io/child'
properties: {
NSRecords: [for dnsServer in childDomain.properties.nameServers: {
nsdname: dnsServer
}]
}
}
```

Unfortunately, just like ARM I can't do this in a single file. In the case of Bicep I get a warning for the ```childDomain.properties.nameServers``` usage.

**Describe the solution you'd like**
If I could wave a magic wand, ARM would be able to handle this. But assuming this platform limitation is hard to remove I'd like Bicep to do the heavy lifting for me. When I look at the way the DNS Zone extension for the Azure Portal solves this, it calls out to a separate deployment template which takes care of the delegation.

If my magic wand isn't as powerful I would love Bicep to support the concept of a inline modules which if used results in two JSON templates being generated from the build taking care of the references for me. It might look something like this:

```bicep
param baseDomainName string = 'parent'
param location string = resourceGroup().location

resource parentDomain 'Microsoft.Network/dnsZones@2018-05-01' = {
name: '${baseDomainName}-domain.io'
location: location
}

resource childDomain 'Microsoft.Network/dnsZones@2018-05-01' = {
name: 'child.${baseDomainName}-domain.io'
location: location
}

module delegateDomains = {
resource childDomainDelegation 'Microsoft.Network/dnsZones/NS@2018-05-01' = {
name: '${baseDomainName}-domain.io/child'
properties: {
NSRecords: [for dnsServer in childDomain.properties.nameServers: {
nsdname: dnsServer
}]
}
}
}
```

I'm not too attached to the syntax, but the idea is that an inline module is just a module where there is no reference to another ```.bicep``` file and the parameters and outputs are inferred from what is consumed-from/used-by the enclosing scope.

Start with the Bicep examples in this issue and reproduce the warning on childDomain.properties.nameServers, then compare the separate deployment-template approach described. Done means inline modules can express the delegation scenario and produce the required deployment templates without the reported reference limitation.

Written by the indexing model from the issue text.