fix: support skipping unread header sizes of ResChunk

[iBotPeaches]

fixes: #2989

Sample application is reporting a larger header size than it should be - packing with bogus data.

00000000: 0200 1000 241c 4200 0100 0000 5353 544b  ....$.B.....SSTK
00000010: 0100 1c00 348b 0e00 a664 0000 0000 0000  ....4....d......
00000020: 0001 0000 b492 0100 0000 0000 0000 0000  ................
00000030: 0e00 0000 1c00 0000 2a00 0000 3800 0000  ........*...8...

Apktool will now compare the difference actually read vs reported to correct.

[iBotPeaches]

Hmmm want to revisit this. This was written for header size, but depending on chunk type will be checked on chunk full size, which won't have as much protection as intended.

However patching that might require another rework.

[iBotPeaches]

Okay I do want to merge this, but I'll probably regret it. We need to adjust a split of header/body reading for the chunks. This patch is intended when we have like a 16 byte header, but only read 12 bytes. Its a technique to break tools and we solve it with this.

However, then we read the string block and we read the header then power through and read the data of that pool, so by the time we hit this function you see - the difference is mega negative since we exceeded the header. The function also doesn't really depict its related to solely the header size.

I think I'll put this on hold and add like a onHeaderRead event and lodge it into every chunk read so we have an entry point after the header read prior to body read.