Probably resolves https://github.com/google/fscrypt/issues/382

The latest version of gofmt flattens the nested lists in comments in
crypto.go and filesystem.go.  According to
https://go.dev/doc/comment#mistakes, "Go doc comments do not support
nested lists".  However, that page also mentions that a workaround is to
use different list markers for each level.  Do that.

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.

Upgrade dependencies to latest version

github.com/golang/protobuf/proto has been deprecated in favor of
google.golang.org/protobuf/proto, so migrate to the non-deprecated one.

Currently, fscrypt policies and protectors are world readable, as they
are created with mode 0644.  While this can be nice for use cases where
users share these files, those use cases seem to be quite rare, and it's
not a great default security-wise since it exposes password hashes to
all users.  While fscrypt uses a very strong password hash algorithm, it
would still be best to follow the lead of /etc/shadow and keep this
information non-world-readable.

Therefore, start creating these files with mode 0600.

Of course, if users do actually want to share these files, they have the
option of simply chmod'ing them to a less restrictive mode.  An option
could also be added to make fscrypt use the old mode 0644; however, the
need for that is currently unclear.

Since fscrypt replaces metadata files rather than overwrites them (to
get atomicity), their owner will change to root if root makes a change.
That isn't too much of an issue when the files have mode 0644.  However,
it will become a much bigger issue when the files have mode 0600,
especially because existing files with mode 0644 would also get changed
to have mode 0600.

In preparation for this, start preserving the previous owner and mode of
policy and protector files when they are updated.

Since commit 4c7c6631cc5a ("Set owner of login protectors to correct
user"), login protectors are made owned by the user when root creates
one on a user's behalf.  That's good, but the same isn't true of other
files that get created at the same time:

- The policy protecting the directory
- The protector link file, if the policy is on a different filesystem
- The recovery protector, if the policy is on a different filesystem
- The recovery instructions file

In preparation for setting all metadata files to mode 0600, start making
all these files owned by the user in this scenario as well.