refactor: remove Buffer dependency from EXIF orientation parser

[diegomura]

Summary

The other foliojs modules — png-js, restructure, and fontkit — have all migrated away from Node-specific APIs (notably Buffer) and now operate on plain Uint8Array. PDFKit is the odd one out: it still leans heavily on Buffer, stream, and other Node built-ins throughout the codebase. I think it's time to bring PDFKit in line with the rest of the ecosystem.

Why this matters

• First-class browser support. Today PDFKit requires bundler shims (buffer, stream-browserify, etc.) to run in the browser, and the standalone bundle is bloated by those polyfills. Moving to Uint8Array lets PDFKit run natively in browsers, Deno, Bun, Cloudflare Workers, and other non-Node runtimes with no shim layer.
• Smaller bundles. Dropping the Buffer polyfill alone meaningfully reduces the standalone build size.
• Consistency across foliojs. PDFKit already consumes fontkit and png-js outputs — aligning on Uint8Array removes conversion friction at the seams.
• Simpler, more portable code. Fewer runtime-specific branches, and the helpers (readUInt16BE, toBinaryString, etc.) are small, testable pure functions.

Approach

Rather than one mega-PR, I'd like to do this incrementally, one module/area at a time, so each change is small, easy to review, and safe to ship behind the existing test suite.

This PR kicks things off with the EXIF orientation parser in lib/image/jpeg.js and introduces lib/binary.js with the shared Uint8Array helpers that future PRs will build on.

Test plan

• npm test — all 362 tests across 53 files pass
• Verify visual test snapshots are unchanged
• Spot-check a JPEG with EXIF orientation in a generated PDF

@blikblum @devongovett would you be onboard of this? I'm trying to start using upstream pdfkit again in react-pdf but things this effort will unblock are mandatory for that to happen. I'll push these changes first on my fork there, but I'd still like to have them merged here for anyone using this lib can benefit from them