This hopefully resolves https://github.com/google/fscrypt/issues/382.

Since Go 1.16 (which recently became the minimum supported Go version
for this project), the package io/ioutil is deprecated in favor of
equivalent functionality in the io and os packages.  staticcheck warns
about this.  Address all the warnings by switching to the non-deprecated
replacement functions.

Following the example of /proc/self/mountinfo, replace the space,
newline, tab, and backslash characters with octal escape sequences so
that the output can be parsed unambiguously.

This is needed to allow creating protector links to btrfs filesystems.

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

This is needed to make FindMount() work on btrfs filesystems.

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

Add back the mountsByPath map, which indexes all Mounts by mountpoint.
This is needed again.

To avoid confusion, also rename two local variables named mountsByPath.

mountsByPath won't contain nil entries, so also make AllFilesystems()
use it instead of mountsByDevice.  This shouldn't change its behavior.

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

Currently, linked protectors use filesystem link files of the form
"UUID=<uuid>".  These links get broken if the filesystem's UUID changes,
e.g. due to the filesystem being re-created even if the ".fscrypt"
directory is backed up and restored.

To prevent links from being broken (in most cases), start storing the
mountpoint path in the link files too, in the form
"UUID=<uuid>\nPATH=<path>\n".  When following a link, try the UUID
first, and if it doesn't work try the PATH.  While it's possible that
the path changed too, for login protectors (the usual use case of linked
protectors) this won't be an issue as the path will always be "/".

An alternative solution would be to fall back to scanning all
filesystems for the needed protector descriptor.  I decided not to do
that, since relying on a global scan doesn't seem to be a good design.
It wouldn't scale to large numbers of filesystems, it could cross
security boundaries, and it would make it possible for adding a new
filesystem to break fscrypt on existing filesystems.  And if a global
scan was an acceptable way to find protectors during normal use, then
there would be no need for link files in the first place.

Note: this change is backwards compatible (i.e., fscrypt will continue
to recognize old link files) but not forwards-compatible (i.e., previous
versions of fscrypt won't recognize new link files).

Fixes https://github.com/google/fscrypt/issues/311

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.

Update the /proc/self/mountinfo parsing code to allow selecting a Mount
with Subtree != "/", i.e. a Mount not of the full filesystem.  This is
needed to allow fscrypt to work in containers, where the root of the
filesystem may not be mounted.

See findMainMount() for details about the algorithm used.

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