feat: Updated PE scope to create the PE next to the primary resource by default

[AlexanderSehr]

Description

Background: #3835 (comment)
Linked to: Azure/Azure-Verified-Modules#1857

Changes the deployment so that the main resource's (e.g., Key Vaults) RG is used as the default location for the PE. The already implemented resourceGroupResourceId will continue to allow the user to specify a different RG (in a different subscription, if needed).

The primary change is from

    scope: resourceGroup(
      split(privateEndpoint.?resourceGroupResourceId ?? privateEndpoint.?subnetResourceId, '/')[2],
      split(privateEndpoint.?resourceGroupResourceId ?? privateEndpoint.?subnetResourceId, '/')[4]
    )

to

    scope: resourceGroup(
      split(privateEndpoint.?resourceGroupResourceId ?? resourceGroup().id, '/')[2],
      split(privateEndpoint.?resourceGroupResourceId ?? resourceGroup().id, '/')[4]
    )

I'll quote from @ahmadabdalla on this matter

In most scenarios, PEs are deployed alongside their main resource in their own RG vs. the VNET RG. Customer app teams may have subnet join permissions on a centralised VNET in a Landing zone, but may not have permissions to deploy into it. Also considering billing and resource lifecycle perspective.

cc: @JamesDawson

Ref: #4449

Pipeline Reference

Pipeline

Type of Change

• Update to CI Environment or utilities (Non-module affecting changes)
• Azure Verified Module updates:
  • Bugfix containing backwards-compatible bug fixes, and I have NOT bumped the MAJOR or MINOR version in version.json:
    • Someone has opened a bug report issue, and I have included "Closes #{bug_report_issue_number}" in the PR description.
    • The bug was found by the module author, and no one has opened an issue to report it yet.
  • Feature update backwards compatible feature updates, and I have bumped the MINOR version in version.json.
  • Breaking changes and I have bumped the MAJOR version in version.json.
  • Update to documentation

[microsoft-github-policy-service]

Important

The "Needs: Triage 🔍" label must be removed once the triage process is complete!

Tip

For additional guidance on how to triage this issue/PR, see the BRM Issue Triage documentation.

[microsoft-github-policy-service]

Important

If this is a module-related PR, being submitted by the sole owner of the module, the AVM core team must review and approve it (as module owners can't approve their own PRs).

To indicate this PR needs the core team''s attention, apply the "Needs: Core Team 🧞" label!

The core team will only review and approve PRs that have this label applied!

[ReneHezser]

LGTM

[ReneHezser]

LGTM