Builtin policies should be preferred over custom ones

[TeamDman]

Currently, the solution deploys a policy definition for each tag to be inherited, but curiously each of those definitions is parameterized for the tag. Instead, the built-in parameterized definitions should be used.

Inherit a tag from the resource group if missing

Inherit a tag from the subscription if missing

would need to update the bicep to remove the definitions

https://github.com/Azure/CanadaPubSecALZ/blob/9fe82b8b4d8fe02ac073b81e808f2a16cbf81a08/policy/custom/definitions/policyset/Tags.bicep

and probably remove the unneeded jsons

https://github.com/Azure/CanadaPubSecALZ/blob/9fe82b8b4d8fe02ac073b81e808f2a16cbf81a08/policy/custom/definitions/policyset/templates/Tags-Inherit-Tag-From-ResourceGroup/azurepolicy.json

https://github.com/Azure/CanadaPubSecALZ/blob/9fe82b8b4d8fe02ac073b81e808f2a16cbf81a08/policy/custom/definitions/policyset/templates/Tags-Inherit-Tag-From-Subscription-To-ResourceGroup/azurepolicy.json

[TeamDman]

Require a tag on resource groups also has a built-in Audit a tag on resources doesn't have a built-in from what I can tell, but it shouldn't be copied for each tag since the param lets one be used everywhere

[TeamDman]

turns out the inherit a tag from subscription conflicts with inherit a tag from resource group because the built-in subscription inherit isn't quite doing the same as this repo's inherit from subscription to resource group since the built-in applies to resources not just subscriptions.

This leads to errors when creating stuff:

CreateOrUpdate: Failure sending request: StatusCode=409 -- Original Error: Code="ConflictingAppendPolicies" Message="Found conflicting policies that modify the same field. Fields: 'tags[Environment]'...

Additionally, using the built-ins instead of duplicating for each tag has a degraded experience in the portal because Azure doesn't show reference IDs unless you're looking at the definition :/

Until Azure improves the portal, probably best to continue duplicating for now.