Consider a size value type for byte-size parameters

[dfa1]

What

Follow-up to #93. Several public methods take a raw long/int for a byte size,
with no client-side validation before the value reaches native code:

• Zstd.decompress(byte[], int maxSize)
• Zstd.compressBound(long srcSize)
• Zstd.estimateCompressDictSize(long dictSize, ZstdCompressionLevel level)
• Zstd.estimateDecompressDictSize(long dictSize)
• ZstdDictionary.train(List<byte[]>, int maxDictBytes) and the trainCover/trainFastCover overloads
• ZstdOutputStream.withPledgedSize(OutputStream, ZstdCompressionLevel, long pledgedSrcSize)

Worth exploring a dedicated size value type (e.g. record ZstdByteSize(long value),
non-negative, maybe with a compact constructor guard) for the same reasons #93
gives for ZstdCompressionLevel: discoverability and fail-fast validation instead
of relying on zstd's native error path.

Context

Raised while implementing #93 — once int level became ZstdCompressionLevel,
the remaining raw long/int size parameters on the same methods stood out as
the next naked primitive.

Counterpoints to weigh (by analogy with #93's discussion)

• Unlike compression level, a byte size has one obvious valid range (>= 0,
  maybe <= Integer.MAX_VALUE for the byte[]-bound cases) — much less
  discoverability value than named compression-level constants.
• int maxDictBytes and long dictSize/pledgedSrcSize are different types
  today; a single value type would need to pick one width (or two types), and
  the int/long split already exists for a reason (byte[] vs. native
  segment sizes).
• Same broad-surface-area cost as Consider a ZstdLevel value type instead of raw int level #93: touches most of the same methods again.

Ask

Same as #93: worth a design discussion before implementation — is validating
"non-negative size" client-side a real win over the current native error path,
and if so what should the type be called and where should it apply (all size
params, or just the ones with a natural upper bound like maxSize/maxDictBytes)?

[dfa1]

why? see https://dfa1.github.io/articles/your-compiler-is-already-part-of-your-security-team.html and also https://dfa1.github.io/articles/rethink-domain-primitives-with-valhalla.html for post-valhalla ideas