feat: Enable the introduction of utl modules in CI & utilities

[AlexanderSehr]

Description

• Enable the introduction of utl modules in CI (e.g., testing) & utilities (e.g., readme generation)
• Using [Module Proposal]: avm/utl/general/get-environment Azure-Verified-Modules#898 as the backdrop
• Updated readme to deal with functions and enabled it to only add specific parts if they have content (like telemetry disclaimer only if there's telemetry)

Special changes

• Utility modules don't necessarily have a telemetry deployment as they are not actually deployed
• We may not have 'usage examples' in the readme for utility modules if they only export functions and don't actually deploy anything

Notes/changes to static tests

• Any module that does not deploy any parameters is not tested for telemetry (parameter/deployment/condition/output)
• Resource group output is only expected for modules that contain resource deployments (as opposed to all modules in the rg scope)
• utl (like ptn) modules are not tested for the existence of a waf-aligned e2e test
• utl (like ptn) modules are not tested for the existence of a defaults e2e test
• e2e tests only require a serviceShort parameter if they deploy resources (as opposed to always)
  • Noticed that the test was duplicated, so I removed one
• e2e tests only require a namePrefix parameter if they deploy resources (as opposed to always)
• e2e tests only require a module deployment using the syntax module testDeployment '../.*main.bicep' = if they deploy resources (as opposed to always)
• e2e tests only require -test- in their test deployment name only if they deploy resources (as opposed to always)

Removal changes

• As the example utility module only exports functions, the removal logic had to be adapted to not only work if resources are deployed
• The logic now differentiates in between 'I can not find a deployment' and 'I can find a deployment, but it has no resources linked' (before it was only the former)
• Further, the logic was slightly altered to not give up as soon as no deployment is found, but instead try and find as many as possible and only throw an exception after the removal logic ran end to end.

If interested, this is how modules would look like.

TODO

• Find out why bicep build fails the example template
• Test CI with new utility module(s)
• Retest CI for res & ptn modules
• Run all custom utilities for res & ptn, as well as utl modules
• Remove avm/utl/general/get-environment function after all tests passed
• Remove avm/utl/general/any-deployment-script function after all tests passed

Closes #2755

Pipeline Reference

Pipeline
(fails because the module isn't existing in AVM)
Successful deployment run
Successful deployment run

All workflows run

Pipeline
(unrelated, WAF-reliability tests failed)
(unrelated, WAF-reliability tests failed)
(unrelated, WAF-reliability tests failed)
(unrelated, WAF-reliability tests failed)
(unrelated, WAF-reliability tests failed)
(unrelated, WAF-reliability tests failed)
(unrealted, WAF-reliablity tests failed)
(unrealted, WAF-reliablity tests failed)

Platform pipelines

Pipeline
(unrelated)
(unrelated permission issue)
(unrelated permission issue)

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

[AlexanderSehr]

Moving to draft until #2999 is merged

[eriqua]

🆗