b:845698 adds functionality to pre-allocate multiple filesystem blocks for
USB-enrollment data during the recovery image building procedure.

We should have a self-contained script that can perform the patching of a
recovery image in the same way a future user-facing tool would (specifically,
without mounting the image), so that we have some sort of reference and can work
out kinks in it. We could then use it as a base when implementing the
functionality in the tool (looks likely it'd be in JS).

This is somewhat tricky, since we scan on increments of a specific block size
(doing an O(n^2) search on gigabytes of data in a user-facing tool is
suboptimal, but the impact is reduced by several orders of magnitude when
scanning for data aligned to block boundaries). However, we have no immediate
way of knowing what block size was used when generating the image.

A solution requiring a minimal amount of code would be to read the partition
table in the GPT header, find the offset of the stateful partition, then read
the block size from the ext4 superblock. Then the pre-allocated config pattern
could be scanned for in block size increments from the base of the ext4
partition.

The config file itself is populated with a binary, null-delimited key-value
format:

  key1\0value1\0key2\0value2\0...

This should be easier to work with than JSON or XML data, and requires a minimal
parser with a smaller attack surface.