We already had code to close open host files when reading or writing a
savestate, but due to d35fe1b we also need to close open guest files
when reading a savestate, otherwise DoStateRead fails to delete them.

I was considering an alternative solution where instead of copying and
clearing m_handles, we just set `handle.opened = false;` for each handle
before reading a savestate (but not before writing a savestate).
However, this wouldn't solve the problem of DoStateWriteOrMeasure's
calls to OpenFile failing due to all handles being open. I'm not aware
of any games that have that many handles open, though.

Log each rejected ELF header, range, and symbol reference. This
provides actionable diagnostics for malformed files without changing the
validation behavior.

ElfReader trusted table offsets and counts from standalone ELF files.
Malformed input could make it read and write past the loaded file buffer.

Validate the ELF header, table ranges, segment data, section data, and
string-table references before accessing them. Invalid files use the
existing executable boot failure path.

NetPlay save synchronization decoded remote LZO blocks with the unsafe
decoder and no output capacity. A malicious host could overflow a client
buffer with a block larger than its declared size.

Use the bounds-checking decoder, validate the declared output length, and
grow buffer results only after each checked block has been decoded.

A malicious dol could theoretically use integer wraparound to bypass
bounds checking and cause DolReader to read past the end of m_bytes.

Could result in crashes, wasting large amounts of memory, or even the
disclosure of heap memory contents.

IOS and IPL reject non-32byte aligned sections

A malicious GCZ file could probably force this to be negative.
Shouldn't cause any issues other than file read failures, but need to fix
because it is causing errors on MSVC.

SectorReader::ReadChunk does do some validation on it, but it only
checks against the original disc size (reported by the GCZ file).
It has no idea how many blocks the header claimed the disc had.

A maliciously crafted GCZ file could trigger read overflows off the end
of the m_block_pointers/m_hashes arrays.

It comes unverified from the file, and a maliciously crafted file could
trigger not one, but two buffer overflows in the heap.