Add support for Inno Setup 6.4.2 through 6.7.1

[dscho]

This series teaches innoextract to parse installers built with Inno Setup 6.4.2 through 6.7.1. Upstream currently bails out on the new SetupID magic strings, and even past that point the on-disk layout has changed substantially across the 6.4.x, 6.5.x, 6.6.x and 6.7.x lines (new header fields, the encryption metadata moved out of TSetupHeader into a separate outer-stream TSetupEncryptionHeader, an ISSig key array between directories and files, 64-bit offsets and sizes, dark-mode wizard image groups, padding bytes in the option bitsets, and so on). The motivation is concrete: recent Git for Windows installers are built with Inno Setup 6.7.x, and innoextract --info / --list are useful enough on those that I wanted them to keep working.

Opening as a draft because I''d like your eyes on the structural choices before polishing.

The 11 commits are split so each one builds and runs independently (verified via git rebase --exec ''ninja innoextract'' from the upstream merge-base). Each commit message cites the relevant Projects/Src/Shared.Struct.pas snippets at the corresponding is-X_Y_Z tag of https://github.com/jrsoftware/issrc as evidence, so the per-version deltas can be cross-checked against issrc directly rather than against my prose.

Roughly, the shape is: commit 1 adds the setup loader v2 offset table (Inno Setup 6.5.0+) in a minimal form that truncates back to uint32 so the seek chain need not change yet; commits 2, 3, 4 cover the simple per-version magic strings plus straightforward header field additions and the TSetupHeaderOption reshuffle through 6.6.1; commit 5 is a pure type widening of offsets, chunk_location and slice_reader::seek to 64 bits with no behaviour change; commit 6 then makes the loader-v2 path and the 6.7.0 block header consume native Int64, so >4 GiB installers are parsed without silent truncation; commit 7 adds bytes_consumed() and discard_padding_to(target) helpers on stored_flag_reader<>; commits 8, 9, 10 cover the 6.5.0 / 6.5.2 / 6.6.0 entry stream reworks (encryption header split-out, the TSetupISSigKeyEntry array, the optional 7-Zip DLL outer stream, the TSetupFileEntry and TSetupFileLocationEntry reshuffles, the 64-bit StartOffset, the TSetupLanguageEntry rework, dynamic-dark wizard images); commit 11 covers the 6.7.0 / 6.7.1 changes (the five shUsePrevious* flags promoted out of the option bitset into expression-string header fields, three new wizard colour fields, TSetupWizardLightControlStyling, the shUnusedPadding=56 / foUnusedPadding=56 padding handled via discard_padding_to(8), Level narrowing on components and tasks, and the new WizardBackImageFile image group).

A few design points worth flagging explicitly, since they are deliberate and a reviewer might otherwise pick at them:

For 6.5.0+ installers, TSetupHeader now clears password.type and password_salt rather than leaving password.type = PBKDF2_SHA256_XChaCha20. With the encryption metadata moved out to the outer-stream TSetupEncryptionHeader, leaving the in-header password type set would make --info report "Setup is passworded!" for every 6.5.0+ installer regardless of whether EncryptionUse is actually euNone. Clearing it preserves the upstream "Setup is not passworded!" output for the unencrypted case.

The 6.7.0 bitset padding is handled via flagreader.discard_padding_to(8) rather than hard-coded byte reads, so it survives future flag-count changes within innoextract itself without re-derivation of the padding constant.

ISSig keys are loaded into a proper issig_key_entry struct via the standard load_entries(...) mechanism (new src/setup/issigkey.{cpp,hpp}, new ISSigKeys entry_types flag, new info::issig_keys vector). Callers that opt in via ISSigKeys get the keys; callers that don''t get the same skip-only behaviour the inline path would have had.

The per-file ISSig SHA-256 digest is stored in the existing (and, on the relevant code path, previously unread) file_entry::checksum field rather than a newly invented verification_checksum. The trailing unconditional checksum.type = crypto::None reset is gated to < 6.5.0 so the hash survives.

Verification I ran locally: innoextract --info against a 6.7.0 Git for Windows installer reports Inspecting "Git" - setup data version 6.7.0 (unicode), Setup is not passworded!, Done., and exits 0; innoextract --list on the same installer enumerates 9409 entries, all paths within the installer; and git rebase --exec ''ninja innoextract'' from the upstream merge-base succeeds for all 11 intermediate trees.

Out of scope for this series, deliberately:

The CMakeLists.txt Boost 1.89.0 build fix and the CI-matrix updates from #205 are not included here. Happy to fold them in (or send a separate PR) if you''d prefer.

Decryption of 6.5.0+ encrypted installers is not implemented. The TSetupEncryptionHeader is parsed and validated, but EncryptionUse != euNone produces a warning and the file body is not decoded.

Dark-mode wizard images (6.6.0+) and the dark variant of the 6.7.0 back-image group are read for stream alignment but not surfaced beyond the new info::wizard_images_back vector for the non-dark 6.7.0 group.

For transparency: #205 by @pelya is a parallel in-flight attempt at the same scope, also still in draft. This series was developed independently; I used #205 only as a confirmation reference for which Inno Setup version first touched which field, not as a source to copy from. There are several deliberate divergences from #205 worth being aware of when you compare them, namely the password.type clearing for 6.5.0+, the native 64-bit consumption in the loader-v2 and block paths rather than truncation back to 32-bit, the discard_padding_to(8) helper instead of hard-coded padding reads, the < 6.4.3 gate (rather than < 6.5.0) for the TSetupFileLocationEntry cleanup based on issrc commits 6aec0a55 and 00d335b7 first appearing at is-6_4_3, the dedicated issig_key_entry data structure rather than skip-only handling, and the reuse of the existing file_entry::checksum field for the per-file ISSig digest. I''m happy to coordinate with @pelya if you''d rather take one branch as the basis and have the other rebased on top.