Out-of-date determination

The main task for build system is deciding if the target is out-of-date
and needs rebuilding. The single most reliable way to do that is to
compare file's content with previously recorded one. But that is too
expensive.

So direct content storage/comparison can be replaced with
collision-resistant hash function of enough length. goredo
uses BLAKE3 with 256-bit output for that purpose.
=> BLAKE3

Also it stores file's size and its inode number. Obviously if size
differs, then file's content too and there is no need to read and hash it.

But still it could be relatively expensive. So there are additional
possible checks that can skip need of hash checking, based on some trust
to the underlying filesystem and operating system behaviour, controlled
by $REDO_INODE_TRUST environment variable value:

$REDO_INODE_TRUST=none
    Do not trust filesystem at all, except for file's size knowledge.
    Most reliable mode.

$REDO_INODE_TRUST=ctime
    Trust ctime value of file's inode. It should change every time inode
    is updated. If nothing is touched and ctime is the same, then assume
    that file was not modified and we do not try to read its content.
    Unfortunately ctime also changes if link count is updated and
    ownership, that could give false positive decision and force file's
    rereading.

$REDO_INODE_TRUST=mtime
    Trust mtime value of file's inode. It should change every time
    file's content is updated. But unfortunately there are
    => many issues

Pay attention that although mtime is considered harmful (link above),
and is hardly acceptable in build system like Make, because it compares
timestamps of two files, redo is satisfied only with the fact of its
changing, so badly jumping clocks are not so devastating. Modern
filesystem and operating systems with micro- and nano-seconds resolution
timestamps should be pretty good choice for $REDO_INODE_TRUST=mtime.
However GNU/Linux with ext4 filesystem can easily have pretty big
granularity of 10ms.

goredo uses $REDO_INODE_TRUST=ctime by default.

If you move your worktree to different place, then all ctimes
(probably mtimes if you are inaccurate) will be also changed. OOD
check will be much slower after that, because it has to fallback to
content/hash checking all the time. You can use [cmd/redo-depfix]
utility to rebuild dependency files.