Allow scope to be symbolic name or resource ID in Bicep

[1stewart]

Is your feature request related to a problem? Please describe.
When trying to create individual modules for the Azure resources we need, I hit a stumbling block with Microsoft.Insights/diagnosticSettings (https://learn.microsoft.com/en-us/azure/templates/microsoft.insights/diagnosticsettings?pivots=deployment-language-bicep). Bicep expects the scope property to be a symbolic name of a resource, which is easy enough when importing a single, existing resource (https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/scope-extension-resources), however this becomes an issue when we want to create a single Microsoft.Insights/diagnosticSettings module that can be chained downstream in a deployment to create diagnosticSettings for any resource. We either have to have conditional logic to support any existing resource being imported (which becomes difficult because we have to get a resource via its unique resource API, we can't just use the generic microsoft.resources like Get-AzResource, and symbolic names have to be unique), or we have to have multiple modules for diagnosticSettings resources on a per-resource basis, which according to https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/resource-logs-categories is 100+. This seems unfeasible, and a step back from other deployment methods that don't require this resource API coupling. Whenever we'd need to make a change like upgrade the API version and schema, we'd need to do it in multiple places, defeating the purpose of a module doing one thing. As long as Microsoft.Insights/diagnosticSettings is a unique provider it should be deployable in isolation of another provider.

Describe the solution you'd like
Please allow scope to be either a symbolic name or resource ID as per other deployment technologies (even ARM templates), instead of enforcing this pattern of having to couple resources in a single module. This would enable whatever you're trying to achieve with the scope change, but also bring it in to parity with existing deployment methods.

[alex-frankel]

This will be addressed with #2245/#2246