Explicitly mention that "fscrypt" here means the userspace tool, not the
kernel part.  Also write `fscrypt` in code font to emphasize this.

Update https://github.com/google/fscrypt/issues/220

Update https://github.com/google/fscrypt/issues/220

- Mention that a v5.4+ kernel is recommended.

- Mention that policy_version defaults to 1 when unset.

- Emphasize that v2 policies are the recommended solution to the key
  visibility problems, and add some more information.

Since on new kernels v1 encryption policies are deprecated in favor of
v2, update the examples to show v2.  This mostly just consists of
updating the output, as the commands are essentially the same with one
notable difference in 'fscrypt lock'.

There's no real need to allow users to choose the key description prefix
(a.k.a. the "service"), since on ext4 and f2fs we can just use "ext4"
and "f2fs" for compatibility with all kernels both old and new, and on
other filesystems we can just use "fscrypt".  So, let's do that.

Since this removes the point of the "--legacy" option to 'fscrypt setup'
and the "compatibility" field in /etc/fscrypt.conf, remove those too.

Specifically, we start ignoring the "compatibility" in existing config
files and not writing it to new ones.  The corresponding protobuf field
number and name are reserved.  We stop accepting the "--legacy" option
at all, although since it was default true and there was no real reason
for anyone to change it to false, probably no one will notice.  If
anyone does, they should just stop specifying the option.

Note that this change only affects user keyrings and thus only affects
v1 encryption policies, which are deprecated in favor of v2 anyway.

When 'fscrypt setup' sees that /etc/fscrypt.conf doesn't exist, don't
ask for confirmation before creating it.  Just do it.  This is the
normal use, and there's not a good reason to ask the user to confirm it.

Resolves https://github.com/google/fscrypt/issues/181