revert flate decode handling to more lenient processing

[EliotJones]

As discussed here #1186 (comment)

the change to use zlib/a adler checksum verification flow meant that invalid flate streams would not be decoded correctly. this caused issues for files that included invalid/missing checksums. this reverts the processing to the old approach for files like #1235

I'd like to check with @rhuijben before merging though to see if I'm missing the main reasons for the initial change, but in the meantime we'll run the tests on this PR to check what it would break.

[BobLd]

@EliotJones fyi tests are failing

[EliotJones]

So I don't see a way to pass Issue953_IntOverflow currently and I somehow broken the build on Mac.

I ended up having a larger refactor of some of the stuff we added for the file fuzzing checks since some of it seemed a bit too much like a workaround.

In summary long is changed to XrefLocation for all object offsets read from the Xref table/stream or brute forced. This is so that object stream values can be distinguished from file values properly without the use of negative sentinel values which would be vulnerable to other malformed files. I'm interested to see how badly this blows up performance.

I removed the check for object number 30 with offset -30 by using the new XrefLocation type. I also changed a bit how cycle detection happens and made it much more strict (max 7) while also using a Span<int> to detect cycles even earlier.

[EliotJones]

@BobLd this should be good to go now. I've added a test for the true cause of the int overflow issue but I haven't fixed it yet. We would need to rework the PDF page content stream parser to recover from corruption better which is a bigger undertaking so I'm fine to let the current exception be thrown for now.

[BobLd]

@EliotJones thanks a lot for that! Let's merge as it is and for performance impact, [UglyToad.PdfPig.Benchmarks](https://github.com/UglyToad/PdfPig/tree/master/tools/UglyToad.PdfPig.Benchmarks) could be used

[rhuijben]

Thanks for the heads-up. For my usecases I would prefer to see just that the PDF is corrupt, instead of trying to expand untrusted most likely invalid data... But I can see cases where others like to recover every last bit of data.