FileFunctions: bail out when wxZipInputStream stalls on a bad entry - #553

UnpackZipFile() reads each interesting zip entry with

    while (!zip.Eof()) {
        zip.Read(buffer, sizeof(buffer));
        target.Write(buffer, zip.LastRead());
    }

When wxZipInputStream encounters an unsupported compression method
(or any other entry-level decompression error), Read() emits one
'Error: unsupported Zip compression method' wxLogError, returns
zero bytes, and leaves the stream in an error state -- but Eof()
keeps returning false. The loop then spins forever, re-emitting
the wx error on every iteration. Reproduced standalone with a
hand-crafted zip whose entry uses compression method 0xff: 50
iterations to reach the test cap, would have run unbounded.

amule-project#376 was a malformed (or just newer-method) eMule-security
ipfilter.zip on 2024-08-04. Affected daemons logged gigabytes of
identical error lines per minute until disk filled or the user
killed the process. Multiple users reported it within a day, then
the upstream feed got fixed and the symptom went away -- but
nothing prevents the next bad zip from doing the same.

Break the inner loop when Read() returns zero bytes. The wx error
still surfaces exactly once (so the operator sees what failed); no
target data was written so target.Length() is 0; UnpackZipFile
returns false; UnpackArchive returns EFT_Error; the IPFilter
reload caller logs its own 'Failed to load ipfilter.dat ...
unknown format encountered.' and abandons the file. Next IPFilter
fetch picks up a clean copy as before.

Verified on Ubuntu 26.04 ARM64, libwx 3.2:

  original loop, hand-crafted bad zip: 50+ iterations
  fixed loop:                          1 iteration, clean exit

Closes amule-project#376