Compare output is... just output. We shouldn't need to pass two "-q"
options to shut it up.

Likening the metastore MSG_* levels to syslog() LOG_* levels, MSG_DEBUG
works like LOG_DEBUG, and the WARNING/ERROR/CRITICAL also have similar
roles. That leaves MSG_NORMAL as the equivalent of LOG_INFO, and
MSG_QUIET as the equivalent of LOG_NOTICE.

LOG_NOTICE is documented as for "normal, but significant, condition"
which tracks what MSG_QUIET is for - things that aren't errors, but that
you want to know about even when you've asked for quiet.

Whereas the output of "compare" is just regular output. Finding a
difference isn't a significant condition - it's exactly what you've
asked it to look for.

This makes `metastore` more useful in scripts, just to check if it found
anything, in the same way as `diff` and `grep`.

Note that POSIX requires that EXIT_SUCCESS is 0, and EXIT_FAILURE is 1,
so I've defined EXIT_DIFFERENCES as 2 which, while different from the
values `diff` and `grep` use (1 for finding something, 2 for errors),
maintains a certain amount of backwards compatibility with previous
versions of metastore.

If you're storing metadata in a version control system with multiple
branches, mtime differences are going to produce a whole bunch of
conflicts that you likely don't care about. This allows you to not
save mtime and avoid those.

Note that we use a sentinel value of -1 for the mentry `mtimensec` field
to indicate this in the data, as all values of `mtime` are theoretically
valid, but `mtimensec` must always be between 0 and 999,999,999 in the
real world.

I'm not 100% sure about the mechanism for selecting this feature. The
legacy behaviour for metastore was to save mtimes in the metadata files,
but ignore them for compare/apply by default, with a `--mtime` option to
use the mtime data.

Keeping the legacy behaviour for backwards compatibility, but adding a
`--no-mtime` option to ignore mtimes when saving felt like a reasonable
way of making this happen, but something about it doesn't feel great.

Maybe I just didn't figure out how to make the documentation clear
enough.  ¯\_(ツ)_/¯

This ensures that the files are stable, and not subject to the order in
which the OS returns directory entries. This should prevent unnecessary
changes, and therefore unnecessary merge conflicts.

Only version 0 is supported here.