Writing shared state breaks parallel execution

> ### `az feedback` auto-generates most of the information requested below, as of CLI version 2.0.62

**Describe the bug**

When performing an operation that manipulates shared state (such as the session info), the JSON files are written in a non-atomic manner. This causes parallel invocations to the Azure CLI to fail with errors like `"Failed to load or parse file /home/myself/.azure/azureProfile.json. It will be overridden by default settings"` further corrupting session state.

**To Reproduce**
This is timing dependent, but typically observed when running parallel processes that start by doing `az account set --subscription xyz` to ensure their state is properly set up.

**Expected behavior**
The file is preferably not written if there is no change, or at the very least it uses atomic POSIX file operations to ensure that the files can always be read successfully.

**Environment summary**
This was discovered in a test suite running in Docker (where each test runner starts by ensuring the correct target subscription is configured).

**Additional context**
It can be considered somewhat of an edge case that mutating global state is required, but even if a custom config location is used (in this case solved by a tmpfs volume in Docker). this causes unexpected behaviour when code runs that are supposed to have the same state.
It can be manipulated in application code by copying the state between each parallel invocation, but this requires some "plumbing code" and would in turn require careful testing and be designed to be future-proof w.r.t changes in the way state is handled.