bin/zbm-kcl: use proper offset when overwriting EFI KCL

[ahesford]

Now that we write UEFI bundles with intelligent offsets, zbm-kcl needs to honor that offset when overwriting the built-in KCL. We could split out all sections and recreate the logic to write them with proper offsets and alignment, but the simpler approach adopted here is to scan the existing UEFI bundle with objdump, compute the gap between .cmdline and the next higher section, and use that as an upper bound on the permissible size of any new KCL written to the file.

In practice, this limit should never be encountered; the alignment requirements seem to mean that the minimum gap is 0x1000 (4k) bytes, and I can't imagine somebody is writing 4000 characters to the command line. Anybody pushing this limit should probably just write a custom image anyway.

Regardless, the overarching goal here is to be extremely cautious, so anything that seems out of whack will just cause the overwrite to fail rather than corrupt the image.

[zdykstra]

This reads fairly clear to me. Testing it locally works as expected - success for a small KCL change, failure for a 5,000 byte addition.

The only thing that might be worth adding, in either comments or a commit message is a bit of detail specifically about the (normal) effective size of a KCL change that will be accepted, given the two EFI stubs we've encountered so far.

[ahesford]

Merged, with a comment in the script and the commit message about the expected gap size, to master and v2.2.x. The new zbm-kcl script has also been added to the release assets and the signify sigs updated. (The signatures for the other assets have not changed.)