When an fscrypt command fails and prints an error message, in some cases
it isn't clear that the message is actually an error, e.g.:

    fscrypt encrypt: login protectors do not need a name

Make it clear by always prefixing the message with "[ERROR] ", e.g.

    [ERROR] fscrypt encrypt: login protectors do not need a name

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

Allow root to provide the --all-users option to 'fscrypt lock' to force
an encryption key to be removed from the filesystem (i.e., force an
encrypted directory to be locked), even if other users have added it.

To implement this option, we just need to use the
FS_IOC_REMOVE_ENCRYPTION_KEY_ALL_USERS ioctl rather than
FS_IOC_REMOVE_ENCRYPTION_KEY.

In theory this option could be implemented for the user keyrings case
too, but it would be difficult and the user keyrings are being
deprecated for fscrypt, so don't bother.

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.

Don't force the user to provide a --user argument when running fscrypt
as root if they're doing something where the TargetUser isn't actually
needed, such as provisioning/deprovisioning a v1 encryption policy
to/from the filesystem keyring, or creating a non-login protector.

Also don't set up the user keyring (or check for it being set up) if it
won't actually be used.

Finally, if we'll be provisioning/deprovisioning a v1 encryption policy
to/from the filesystem keyring, make sure the command is running as
root, since the kernel requires this.

Add support for 'fscrypt lock'.  This command "locks" a directory,
undoing 'fscrypt unlock'.

When the filesystem keyring is used, 'fscrypt lock' also detects when a
directory wasn't fully locked due to some files still being in-use.  It
can then be run again later to try to finish locking the files.

In preparation for introducing support for the new filesystem-level
keyrings, move the existing user keyring management code from
security/keyring.go and crypto/crypto.go into a new package, 'keyring'.

This package provides functions AddEncryptionKey, RemoveEncryptionKey,
and GetEncryptionKeyStatus which delegate to either the filesystem
keyring (added by a later patch) or to the user keyring.  This provides
a common interface to both types of keyrings, to the extent possible.

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().

Now the user is persented with help when they try to access a keyring
that isn't theirs or try to use fscrypt without a user keyring linked
into the session keyring.

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.