Re-examine how snippets handle child resources

There are a lot of snippets that create child resources without a corresponding parent resource (e.g. many of the Cosmos DB snippets, the Key Vault secret snippet, the NSG rule snippet, the route table route snippet, SQL Database import, and a generic child resource snippet). Currently, they include a placeholder for the qualified name of the child resource and expect it to include a `/`, e.g. `myparent/mychild`.

Given we are encouraging people to use the `parent` property and nested resources (e.g. #3006, #2245). I think we should figure out how we want to migrate these snippets away from the name concatenation approach.

Options might include:
1. We require that child resource snippets include the parent resource.
2. We add a `parent` property to the child resource definition in the snippet without the corresponding parent resource being included. However, this results in test failures today, because the emitted Bicep file is checked for validity.
3. We add an `existing` resource to the emitted Bicep file and use that as the `parent`.

Start by locating the snippets for Cosmos DB, Key Vault secrets, NSG rules, route table routes, SQL Database import, and the generic child resource case. Read the emitted Bicep validity checks and compare the three migration options in the issue. Done means the chosen approach is applied consistently and the affected snippets pass validity tests.

Written by the indexing model from the issue text.