* Release version v0.2.6

Fixes #195

Also, update the encrypted API key.
My person access token had expired, this one should work now.

Signed-off-by: Joe Richey <joerichey@google.com>

While it's important to generate a recovery passphrase in the linked
protector case to avoid data loss if the system is reinstalled, some
people really don't want it (even though it can be safely ignored as it
almost certainly has far more entropy than the login passphrase).

As a compromise, prompt for y/n before generating it, with default y.
Also, to allow disabling the recovery passphrase during noninteractive
use, add a --no-recovery command-line option.

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

Clean up policies and protectors on error

Ensure that when an encryption policy is reverted (e.g. due to
encryptPath() failing after the policy was created), we also delete any
new protector links that were created for the policy, as this is not
handled by the logic that reverts new protectors.

When adding a protector to a policy, don't unconditionally overwrite the
protector link, because it may already exist.  Instead, if it already
exists and points to the mount, just use it.  If it already exists and
points to the wrong place, return an error.

Also add a bool to the return value of AddLinkedProtector() so that
callers can check whether the link was newly created or not.

Move the deferred locking and deletion of the policy on failure to the
correct places, so that it's done in all failure cases, including in the
case where adding the recovery protector fails.

Also make the recovery protector be locked and deleted on failure.

Finally, put all the code to do deferred deprovisioning of the policy in
the same place: right after it's provisioned.

Ensure that a failed AddRecoveryPassphrase() doesn't leave around an
unneeded protector file.

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

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.

If the login protector was just created by the same 'fscrypt encrypt'
command, then policy.Context.Config.Source will be pam_passphrase.  This
needs to be overridden to custom_passphrase when creating the protector
for the recovery passphrase.

This fixes the following error:

    fscrypt encrypt: login protectors do not need a name

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