Improvements to fail()

**Is your feature request related to a problem? Please describe.**
I was testing fail() function and I have some suggestions:
* Currently the error is shown after the deployment reaches failed state. It would be way better if the error can be surfaced on validation rather during deployment. In case there are some scenarios where the validation cannot calculate that fail() will be triggered it is ok if the error appears when the deployment fails.
* I can see this error being generated when fail is executed:


That error is confusing due to a few things:
* It says unable to process language express and it says InvalidTemplate. I do not think this matches the intention of fail. The template is not valid. In this case the user provided parameter domainName without domainGuid. There is nothing invalid in the template. In fact it is intended to fail.
* The resource ID is included in the message. That is somehow redundant information as if you see the error as it appears in Activity log or deployments pane you can clearly see for which resource is intended. So adding the resource into the message makes displaying the same information twice, increases the error type/message in which it puts the most important information - the text for the failure at the end of the sentence.
My suggestions are:
* come up new error code different from InvalidTemplate. It could be simple as Error or Failure or whatever more general error code there is for failure available. InvalidTemplate just does not reflects to what fail() is being used for.
* Do not include the resources into the Errors message. I think it is best that the error message contains only the text that the developer has provided. Putting any other text makes it more confusing.
* Do not put the resource ID into the error message. That information is already available on other place.
* And of course the suggestion to surface the error on validation when possible. My initial expectation was that btw.

**Describe the solution you'd like**
done.

Start by reproducing a Bicep fail() deployment and comparing the validation and deployment error behavior in Azure. Review how the current error is surfaced, including its code, resource ID, and user-provided text. Done means fail() errors are surfaced during validation when possible and use a clearer message and error classification without redundant resource information.

Written by the indexing model from the issue text.