Replace compression-ratio heuristic with absolute uncompressed-size bound

[rootkiller6788]

Fixes #184

Problem

woff2_decompress (and the decoder used by browsers) rejects valid fonts with:

Implausible compression ratio 1952.7

Issue #184 shows a real use case: a font that covers Unicode planes 0, 1 and 15 with a pool of N identical empty glyphs (cmap format 12). Such a font is valid per the spec, and its WOFF2 compresses extremely well because the glyph data is repeated. At N=65534 it compresses from ~533KB to 277 bytes (~1924x), and the ratio check rejects it.

I reproduced this locally: a 8000-glyph font compressing from 65457 to 248 bytes (~264x) was rejected with "Implausible compression ratio 202.0"; with the fix it round-trips byte-for-byte.

Why the ratio check is the wrong guard

The check (added in 2016 as a decompression-bomb guard for the std::vector<uint8_t> uncompressed_buf(hdr.uncompressed_size) allocation) rejects when uncompressed_size / file_size > 100. Two problems:

1. It is bypassable. file_size is just as attacker-controlled as uncompressed_size; an attacker can pad the file so the ratio stays under 100 while claiming gigabytes. It therefore never actually bounded the allocation.
2. It produces false positives. Legitimately highly-compressible fonts (repeated empty glyphs, subset fonts) can exceed any fixed ratio.

The fix

Bound the quantity that actually sizes the allocation directly: reject hdr.uncompressed_size > kDefaultMaxSize (128MB), the same limit the reconstructed output is already subject to via WOFF2StringOut/WOFF2MemoryOut.

A font that can decode successfully reconstructs to at most kDefaultMaxSize, and a valid font's transformed table data is never larger than its reconstructed output, so this bound cannot reject a decodable font. A claim above the limit is rejected before any allocation happens.

Verification

• Crafted the issue's scenario (N=65534, planes 0/1/15): previously rejected at ratio ~1924; now decodes to a byte-identical TTF (all 10 tables match via fontTools).
• Crafted a 8000-glyph variant (ratio ~202): previously rejected; now decodes byte-identically.
• Crafted a decompression bomb claiming 129MB uncompressed in a 68-byte file: rejected by the new bound before allocation ("Implausible uncompressed size 135266304").
• A 100MB claim (under the bound) proceeds to brotli, which fails naturally on garbage input.
• Fuzzed 120 random/mutated inputs through the decoder: 0 crashes.