Feature/Discussion: provide safety net for `create` commands and make them consistent

**Is your feature request related to a problem? Please describe.**

This is prompted by **"https://github.com/Azure/azure-cli/issues/7608: `az keyvault create` silently zaps existing access policy when run on existing vault"**

The crux of the problem is:

- Some/most `create` commands are destructive and will silently do their destructive deed.

- There is no safety net.

- This is not the default behaviour I want in production -- it's too scary.

- Relying on humans not forget to check if resource already exists before
running `create` is not the answer in the absence of safety net.

- With some `create` commands like `az storage container create` being
safe to run at any time, it makes it easier to forget that other commands
are not safe.

- Destructive commands are inconsistent and undocumented in what they destroy:
e.g. `az keyvault create` zaps access policies but leaves the secrets intact.
Practical test seems to be the only way to be 100% sure and it's a poor option.

- It is well within Azure CLI's capabilities to do the "remembering" and
safety net for us and thus provice a better experience here.

-----
**Describe the solution you'd like**

The goal of the solution is:

- Make Azure CLI much safer to use;
- Bring consistency to the all commands;
- Do the "remembering" work for us humans;
- No nasty surprises.

The proposal is:

**For all safe non-destructive `create` commands:**

- A **safe** `create` command is a command which:

- Safe to run at any time
- Never destroys or changes anything if target resource exists
- Actually creates target resource only if it does not exist
- Note that if we run `create` with parameters such that
it would lead to any chages in target resource it is not
a safe command.
- Example: `az group create` (it's safe, right?)

- We can run it at any time just like now.

- Consider for all such commands to have `--fail-on-exist` flag for
consistency (see `az storage container create`).

**For all non-safe destructive `create` commands:**

- A **non-safe** `create` command is any command which:

- Destroys all or part of the target resource (see `az keyvault create`)
- Makes any changes to the target resource if it exists
- Some normally safe commands may become unsafe depending on paramteres.

- Default behaviour for these should be:

- Command always fails if the target resource already exists.
- This reminds people to use `if resource exists; then update; else create` pattern.
- This provides much needed safety net.

- For legacy and "I know what I'm doing" scenarios:

- Supply `--force` or similar flag.
- This will enable to current destructive behaviour for
compatility/whatever other reasons.

-----

**Describe alternatives you've considered**

None really, open to suggestions which work towards the goals stated above.

-----
**Additional context**

- We have lots of people who use Azure CLI infrequently and in production.
It's very hard for them to remember what is safe and what isn't
and exact behaviour of each command, plus remembering to check for
resource existence when required. I include myself in this category.

- We have lots of automation and unattended deployments going on into all
environments, any human error in scripting Azure CLI is a potential disaster.
Making things safer would make things way way better.

-----

EDIT1: corrected link to the issue which prompted this