Missing validation/completions when using `existing` with unresolved discriminated objects

Created from this discussion: https://github.com/Azure/bicep/issues/784#issuecomment-880907755

Example repro of this behavior:
```bicep
resource normal 'Microsoft.DBForMySQL/servers@2017-12-01' = {
name: 'asdfsadf'
location: 'asdas'
properties: {
administratorLoginPassword: ''
administratorLogin: ''
createMode: 'Default'

}
}

// completions work on 'properties'
var normalAccess = normal.properties.version

resource existing 'Microsoft.DBForMySQL/servers@2017-12-01' existing = {
name: 'asdfsadf'
}

// completions do not work on 'properties'
var existingAccess = existing.properties.version
```

My analysis from the comment thread:
> With this particular resource - I think because `properties` is modeled with a `DiscriminatedObjectType`, without the `createMode` (discriminator) supplied, Bicep is unable to figure **which** discriminated path has been selected. Rather than displaying all of the properties, Bicep only supplies the one it knows for sure (`createMode`)

Start by reproducing the two resource-access examples in the issue and compare validation and completion behavior for the normal and existing resources. Investigate how unresolved discriminated objects are handled, then verify that the existing example exposes the appropriate properties and validation after the change.

Written by the indexing model from the issue text.