aria_corrupt_log: tool to find and corrupt fields in an Aria transaction log

aria_corrupt_log would be a small command line tool that opens an Aria transaction log, finds a given record or opcode inside it, and patches one field to a chosen value. It is the log equivalent of what aria_chk does for index files, except it breaks things on purpose instead of fixing them.

It is proposed because the bounds checks added in MDEV-40493 to MDEV-40499 have no good way to be tested today. The first version of those patches forged bad values with DBUG_IF() hooks in the write path, which was rejected in review for putting corruption code in the engine itself. The deeper problem is that a DBUG_IF hook only exists in a debug build, and a debug build is exactly where DBUG_ASSERT still fires, so the hook can never reach the case that matters: a release binary where the runtime check is the only thing standing between a corrupt record and an out of bounds write. Corrupting the log from outside removes that limit, and lets recovery be driven against a normal production binary.

In use it would take the opcode to hit, the field inside it, and the value to write:

aria_corrupt_log --aria-log-dir-path=DIR --corrupt=KEY_OP_MULTI_COPY --field=full_length --value=65000

A test would then run a workload, kill the server, corrupt the log, and restart, expecting recovery to reject the record and mark the table crashed rather than apply it. Because the value is given on the command line, one test can loop over boundary values for a field instead of needing a separate hook per case, which is what makes this scale to the handful of bounds each of these checks guards.