Currently, when a DB is corrupted the Recovery Tool will produce in serial:

1. the *.mv.txt
2. the *.h2.sql (uncompressed)

This PR adds a new tool DirectRecover which

• skips step 1 (using a pipe)
• and writes *.h2.sql with optional compression
• allows optionally for more efficient algorithms BZip2 and KANZI (parallel ZPAQ), both loaded via generic initiation w/o hard dependencies

Test case: ifrsbox.mv.db 1.7GB

with standard Recover:
Dump file: 1.3 GB
SQL file: 3.7 GB

with DirectRecover on 8 core/16 threads Ryzen5
GZIP SQL file: 206.2 MB in 74 secs
Kanzi SQL file: 152.9 MB in 131.24 secs
BZip2 SQL file: 153.7 MB in 18.38 mins

This is a feeler PR to get your feedback.
I am still very much interested in generating the new recovered DB on the fly too.

There are two important use cases for me:

1. efficient backup (e.g. daily over-night snapshots, since H2 still corrupts often).
2. DB recovery of large DBs with limited filespace ( w/o creating 4 large copies of the same DB)