feat: OIDC auth-type SERVICE_PRINCIPAL using msi + Entity type Environment - branch test

[eriqua]

Description

• Tested backward compatibility.
  CI will continue to use Azure login with service principal + secrets (Azure creds) meanwhile OIDC is set up at repo level and in target subscription.
  
• Created OIDC MSI and granted permissions
• Tested feature on all modules as per pipeline badges below
• Implement OIDC exception list, allowing a subset of modules to temporarily leverage SPN + secret meanwhile their blocker gets investigated and fixed
  • Supporting OIDC
    
    
  • Exempted
    
• Update AVM contribution guidelines

Pipeline Reference

Pipeline
--> (exception uses SPN+secrets)
--> (exception uses SPN+secrets)
--> (exception uses SPN+secrets)
--> unrelated
--> unrelated
--> unrelated

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

Checklist

• I'm sure there are no other open Pull Requests for the same update/change
• I have run Set-AVMModule locally to generate the supporting module files.
• My corresponding pipelines / checks run clean and green without any errors or warnings

[AlexanderSehr]

I guess we should update every pipeline that runs an Azure Login with the new parameters. I just saw that for example the deployment history cleanup workflow would need the same (but there may be more)

[eriqua]

I guess we should update every pipeline that runs an Azure Login with the new parameters. I just saw that for example the deployment history cleanup workflow would need the same (but there may be more)

@AlexanderSehr the only other workflow to be updated is the cleanup deployments one (addressed already via another PR). All the others using azure login action are already using oidc, but with the publish credentials