AZ CLI in devcontainer is too tightly coupled to the host machine

The devcontainer mounts the entire ${HOME}/.azure folder to give access to the Azure configuration for the az cli. This means that the host machine cannot upgrade the version of the cli it uses without risking breaking the scripts in the devcontainer, which assume an older version.

Steps to reproduce

1. Go back in time 8-9 months.
2. Create a VM, install the az cli and the AzureTRE code on it.
3. Build the devcontainer.
4. Come back to the present, upgrade the az cli on the host.
5. Attempt to upgrade the AzureTRE deployment, it will fail because the cli version in the container is not compatible with the extension versions mounted from the host.

One fix that seems to work is:

• in devcontainer.json, mount the ${HOME}/.azure to a different location in the container, e.g. /tmp/host-azure
• then, in the post-create.sh script:
  • create the /home/vscode/.azure folder in the container
  • copy the azureProfile.json from /tmp/host-azure to /home/vscode/.azure
  • create az.json and az.sess in the containers' /home/vscode/.azure with an empty json object ({})
  • ensure /home/vscode/.azure in the container is owned & writable by the vscode user
• run az login in the container before getting started with the TRE

This leaves the two az installations completely decoupled, at the price of having to log in explicitly, once, in the container.

Start with devcontainer.json and post-create.sh, then inspect how the host .azure directory and the container's /home/vscode/.azure are currently connected. Test the container after changing the mount and initialization flow, including az login, and confirm host CLI upgrades no longer affect the container's Azure CLI extensions or deployment scripts.