Poor scriptability due to --name not being easily checkable

I'm scripting the creation of some encrypted ext4 folders by calling the `fscrypt` CLI.

While most of the CLI seems designed for scriptability (prompts can be overridden by passing the information with CLI arguments), an unresolved pain point seems to be key names:

* Using `fscrypt metadata create protector` as described [here](https://github.com/google/fscrypt/tree/f91f8e4fcb59d6db80e5150530a65fe39a836eb2#using-a-raw-key-protector), or using `fscrypt encrypt`, requires passing `--name`.
* Passing an existing name give error `there is already a protector named "myname"`.
* But there is no way to programmatically query existing key names.

The only workaround seems to be parsing the output of `fscrypt status /`, which does not look very stable at all.

The bash completion currently does that in this ugly parsing hack:

https://github.com/google/fscrypt/blob/97700817e737eabf45033cdb4a42fa5c6e74f877/cmd/fscrypt/fscrypt_bash_completion#L86-L94

---

Other parts of `fscrypt` provide programmatic queries of whether something already exists, e.g. to check whether a dir is already encrypted one can check the status code of `fscrypt status`, which as per `--help`

> will fail if PATH is not setup for encryption with fscrypt

---

Some ideas to improve scriptability:

* Add a way to check if a key name is already taken.
* Or add e.g. a `--json` flag that turns all output into JSON, similar to how Hashicorp tools like `consul` provide it.
There's the request for #175 but things as simple as key creation should be possible also from the command line.
* Make `fscrypt metadata create protector` succeed instead of fail if the key name already exists AND the given `--source raw_key --key` is the same as the one already stored (that is, make it idempotent), or add a flag to get that behaviour.