Have clear instructions and a simple mechanism for pinning to a Bicep version

[anthony-c-martin]

The following tools expose ways of using Bicep without pinning to a particular version, which is commonly used in CI pipelines:

• AzCLI
• AzPwsh
• ADO task (AzureResourceManagerTemplateDeployment@3)
• GitHub Actions (azure/arm-deploy@v1)
• ADO/GitHub Actions base image

This is problematic when we push out a new release, as it means that customers are instantly upgraded without consent. We should think about designing a simple mechanism for locking to a particular version of Bicep.

Examples of issues that could have been avoided with this (please add as needed):

• Unhandled exception. System.ArgumentException: Unable to determine parent of specified node of type 'FunctionCallSyntax' at span '[468:520]' because it has not been indexed. #13618

[miqm]

Perhaps we could make some setting in bicepconfig for the build to fail if wrong version is used?
in azCLI you can install a particular version so you can pin our CI/CD to one. The problem could be with VSCode as you might see some code working (as your extension had upgraded) but the pipeline is not (as it uses old compiler).

Also, if we're talking about versions it would be nice for az cli to first look for bicep executable on the path and only if not found - to download. This way we could pin the compiler version by i.e. producing custom docker image with cli pre-installed and version being maintained by i.e. dependabot.

[StephenWeatherford]

#12290