When 'fscrypt status DIR' detects that a v1-encrypted directory is still
usable but its key seems to be absent, it shows the status as
"Unlocked: Partially (incompletely locked)".  But actually it can also
be the case that the directory is unlocked by another user.  Adjust the
status message accordingly.

This commit also fixes cli-tests/t_v1_policy.

Introduce filesystem.ErrEncryptionNotEnabled and
filesystem.ErrEncryptionNotSupported which include the Mount as context,
and translate the corresponding metadata/ errors into them.  Then make
these errors show much better suggestions.

Also replace lots of other filesystem/ errors with either custom types
or with unnamed one-off errors that include more context.  Fix backwards
wrapping in lots of cases.

Finally, don't include the mountpoint in places where it's not useful,
like OS-level errors that already include the path.

'fscrypt lock' on a v1-encrypted directory doesn't warn about in-use
files, as the kernel doesn't provide a way to easily detect it.

Instead, implement a heuristic where we check whether a subdirectory can
be created.  If yes, then the directory must not be fully locked.

Make both 'fscrypt lock' and 'fscrypt status' use this heuristic.

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

Implement adding/removing v2 encryption policy keys to/from the kernel.
The kernel requires that the new ioctls FS_IOC_ADD_ENCRYPTION_KEY and
FS_IOC_REMOVE_ENCRYPTION_KEY be used for this.  Root is not required.

However, non-root support brings an extra complication: the kernel keeps
track of which users have called FS_IOC_ADD_ENCRYPTION_KEY for the same
key.  FS_IOC_REMOVE_ENCRYPTION_KEY only works as one of these users, and
it only removes the calling user's claim to the key; the key is only
truly removed when the last claim is removed.

Implement the following behavior:

- 'fscrypt unlock' and pam_fscrypt add the key for the user, even if
  other user(s) have it added already.  This behavior is needed so that
  another user can't remove the key out from under the user.

- 'fscrypt lock' and pam_fscrypt remove the key for the user.  However,
  if the key wasn't truly removed because other users still have it
  added, 'fscrypt lock' prints a warning.

- 'fscrypt status' shows whether the directory is unlocked for anyone.

Linux v5.4 and later allows fscrypt keys to be added/removed directly
to/from the filesystem via the new ioctls FS_IOC_ADD_ENCRYPTION_KEY and
FS_IOC_REMOVE_ENCRYPTION_KEY.  Among other benefits, these fix the key
visibility problems that many users have been running into, where system
services and containers can't access encrypted files.

Allow the user to opt-in to using these new ioctls for their existing
encrypted directories by setting in their /etc/fscrypt.conf:

	"use_fs_keyring_for_v1_policies": true

Note that it can't really be on by default, since for v1 policies the
ioctls require root, whereas user keyrings don't.  I.e., setting this to
true means that users will need to use 'sudo fscrypt unlock', not
'fscrypt unlock'.  v2 policies won't have this restriction.

Make it clear that this refers to a type of filesystem such as "ext4",
rather than to a specific filesystem instance.

Show the encryption options when running 'fscrypt status' on a
directory.  E.g.:

	Policy:   490515286453d3f7
	Options:  padding:32 contents:Adiantum filenames:Adiantum
	Unlocked: Yes

These were found by a combination of manual review and a custom script
that checks for common errors.

Also removed an outdated sentence from the comment for setupBefore().

The --user flag can now be used to have the targe user (the one whose
keyring and password will be used in fscrypt) be different than the
calling user. Very usefull for things like

	sudo fscrypt purge /media/joerichey/usb --user=joerichey

which will now have privileges to drop caches, but will properly clear
the keys from the user's keyring.

Now that we can distinguish between lacking encryption support and
lacking fscrypt metadata, "fscrypt status" can now display this
additional information.