Hashing and stamping

All targets are checksummed if target's size, ctime/mtime differs from
the previous one (depending on [OOD]'s $REDO_INODE_TRUST value).
apenwarr/redo gives many reasons
=> why
every time checksumming is bad, but in my opinion in practice all of
them do not apply.

* Aggregate targets and willing to be out-of-date ones just must not
  produce empty output files. apenwarr/*, redo-c and goredo
  implementations treat non existing file as an out-of-date target
* If you really wish to produce an empty target file, just touch $3

Those who create an empty file if no stdout was written -- are failed
implementations.

redo is a tool to help people. Literally all targets can be safely
"redo-stamp <$3"-ed, reducing false positive out-of-dates. Of course,
with the correct stdout/$3 working and placing necessary results in $3,
instead of just silently feeding them in redo-stamp.

redo implementations already automatically record -ifchange on .do files
and -ifcreate on non-existing .do files. So why they can not record
redo-stamp the same way implicitly? No, Zen of Python is not applicable
there, because -ifchange/-ifcreate contradicts it already.

Modern cryptographic hash algorithms and CPUs are so fast, that even all
read and writes to or from hard drive arrays can be easily checksummed
and transparently compressed, as ZFS with LZ4/Zstandard and
Skein/BLAKE[23] algorithms demonstrate us.

goredo includes redo-stamp, that really records the stamp in the .dep
file, but it does not play any role later. It is stayed just for
compatibility.