Notable features that differentiate goredo from many other implementations.

* explicit useful and convenient checks from apenwarr/redo:
    * check that $1 was not touched during .do execution
    * check that stdout and $3 are not written simultaneously
    * check that generated target was not modified "externally" outside
      the redo, preventing its overwriting, but continuing the build
      (optionally can stop)
* recursive, indented and serialized logs display ability, with
  priority to the depth and bad return codes, like in apenwarr/redo,
  thanks to
  => apenwarr's article
* all environment variables, working directory, command line
  arguments, start/finish times, duration, participated PIDs, return
  codes can be saved for later investigation
* targets, dependency information and their directories are explicitly
  synced (can be disabled, should work faster)
* file's change is detected by comparing its size, and
  => BLAKE3 hash.
  Also as an optimization, by default if file's ctime is same, then hash
  check is skipped. Optionally you can disable that behaviour, or even
  enable trust to file's mtime
* files creation is umask-friendly (unlike mkstemp() used in redo-c)
* parallel build with jobs limit, optionally in infinite mode
* optional coloured messages
* verbose debug messages, including out-of-date determination, PIDs,
  lock and jobserver acquirings/releases
* displaying of each target's execution time
* each target's stderr can be prefixed with the PID
* optional statusline with currently running/waiting/done jobs
* target's stderr can be stored on the disk with TAI64N timestamped
  prefixes for each line. Look at [cmd/Logs].
* [Jobserver] compatibility support with GNU Make and NetBSD bmake.