(#765) Restore Hadoop ByteBuffer compression compatibility

[vjanelle]

Fixes #765.

Hadoop 3.5.0's SnappyCompressor sets its output buffer limit to zero before calling Snappy.compress. The bounds check added in #739 uses remaining(), so it rejects that buffer even when its allocated capacity is sufficient and causes Snappy-compressed SequenceFile writes to fail.

Validate capacity() - position() against maxCompressedLength(input.remaining()) before invoking JNI. This restores the existing output-buffer behavior while preserving the check against insufficient allocated space, including output offsets and slice boundaries. The decompression bounds check protecting against #728 remains unchanged. Update the Javadoc to make the compression output-buffer semantics explicit.

Add five regression tests covering empty output limits, nonzero positions, slices, insufficient capacity after the output position, and undersized slices backed by larger allocations.

Validation:

• ./sbt -batch testFull: 144 passed, 1 ignored, 0 failures.
• Direct Hadoop 3.5.0 SnappyCompressor reproduction: successful compression and roundtrip with the fix; the prior check produces the exact reported exception.
• New empty-limit regression cases fail before the fix; all 39 bounds-check tests pass afterward.

The complete Spark suite has not been rerun with this change.