Start omxplayer only once

Do not start a new omxplayer On switching between live and replay.

Instead, start only one reading from stdin, and control what piped
command group send to its input.
Keep raspivid and omxplayer alive

Organize piped command groups in such a way that we can keep both
raspivid and omxplayer alive.

This avoid to restart (which takes time and has side-effects) on
switching between live and replay.

`raspivid` stdout is piped to a `tee` duplicating the output.

The first is piped to a function called in a subshell (using >()
redirection):
  - In live mode, it saves the H.264 NALs from the last n bytes using
    `pibuf`. It creates a record.h264 file on EOF or stdin errors.
    Therefore, we add a `cat` command between `tee` and `pibuf` for
    being able to kill `cat`, which will make `pibuf` finish and write
    the file.
  - In replay mode, it just `cat` to /dev/null, to eat what raspivid
    produces without killing `raspivid` neither `tee`.

The second is piped to a group of command: a `head` to play the first
bytes of the video immediately (because omxplayer starts its very long
initialization only when it has enough video packets), followed by a
`delay` to keep the stream live-delayed.

This `delay` is piped to a function, itself piped to `omxplayer`:
  - In live mode, this function just call `cat`.
  - In replay mode, it `cat` to /dev/null (so that it eats what `delay`
    produces without killing `delay`) and, in parallel, `cat` the file
    produced by `pibuf` (once dead) to omxplayer.

Thus, on live/replay switching, two parts change their behavior. The
others (`raspivid`, `tee`, {`head`;`tail`}, `omxplayer`) stay alive.
Start cli_loop independantly

Indeed, cli_loop must not be included in the inner commands group, else
it will receive on its stdin the output of raspivid.

Instead, we want to create the architecture of process and call cli_loop
in the current one, for capturing key events.