Revisit our strategy for naming bicep outputs into the environment

[ellismg]

Today after a deployment we take all of the outputs the bicep module we deploy and add them to the .env file (and for .NET apps, we add them to the .NET Secret Store as well).

Since environment variables names are traditionally in SCREAMING_CASE, we used this convention for our bicep modules. However, this is different from typical bicep modules, which will use camelCase (to match the casing of parameters and the properties of azure resources).

As part of @jongio work to refactor our templates into a set of reusable modules, we've run into this problem where some outputs are now SCREAMING_CASE and others are camelCase based on what module they sit in.

It would be nice if there was some way you could denote for a given output that it should be added to the environment (this would let us have outputs that would be useful for code that wants to use this module, but aren't interesting values to slam into your .env file (for example, resource ids) and denote what the name of the key for the value should be in the environment (so we could have bicep outputs which are camelCase but are marked as being added to the environment with names that are in SCREAMING_CASE).

We may be able to leverage the @metdata decorator from bicep to do this mapping. It is not currently supported on outputs, but I recently did a PR which enables this support (it was already supported for arm templates) and that feature will show up in the next bicep release (sometime in October)

[ellismg]

This can fold into the larger environment work I've been doing.

[rajeshkamal5050]

Seems to be an older item and might have been handled as part of the env re-design work. @ellismg feel free to close, if already handled.

Not a must-fix for GA. Moving to Backlog.

@savannahostrowski @ellismg