BZip2: add opt-in tolerateTruncatedStream to decode a footerless/partial stream

[fiddyschmitt]

Hi Adam,

Over at clonezilla-util I use SharpCompress to make a seekable stream out of a bzip-2 stream (see Bzip2StreamSeekable)

That worked in 0.37 but not in later releases due to the way EOF is handled. This PR enables that function once more, in an opt-in fashion.

Thanks!
Fidel

Summary

Adds an opt-in tolerateTruncatedStream parameter (default false) to BZip2Stream.Create /
BZip2Stream.CreateAsync, threaded through to CBZip2InputStream. When enabled, the decoder accepts a
bzip2 stream that has no trailing footer — e.g. a truncated stream, or a sub-range of blocks
extracted for random access — instead of throwing.

Default behaviour is unchanged.

Motivation

Decoding a partial bzip2 stream isn't currently possible. After each block the decoder probes for the
next block/footer header, so the moment the input runs out it throws
ArchiveOperationException("BZip2 compressed file ends unexpectedly"). This makes it impossible to feed
the decoder a slice of blocks (a common technique for random access into large bzip2 files) or any stream
captured without its footer. This brings bzip2 in line with the more forgiving end-of-input handling
elsewhere in SharpCompress, for callers that explicitly opt in.

What it does

When tolerateTruncatedStream is true:

1. End-of-input at a block boundary ends the stream instead of throwing. This is scoped to the point
   where a block/stream header is read (tracked by expectingBlockStart); EOF in the middle of a block,
   the block CRC, or the Huffman tables is still reported as an error, so genuinely corrupt /
   truncated-mid-block input still fails.
2. The whole-stream combined CRC is not verified. A partial decode's running combined CRC can't match
   the value stored in the footer, so that check is skipped. Per-block CRCs are still enforced.

The flag defaults to false (no behaviour change), and the change is applied symmetrically to the sync
and async read paths. One internal caller (BZip2CompressionProvider) was updated for the new optional
parameter.

Tests

Added to BZip2StreamTests:

• a footerless, header-only stream decodes to empty with the flag and throws without it;
• a real block followed by end-of-input at the next block boundary decodes with the flag and throws
  without it;
• a corrupted whole-stream combined CRC is tolerated with the flag and fatal without it;
• a complete, well-formed stream still round-trips with the flag set (no regression).

All existing BZip2 tests continue to pass.

[adamhathcock]

sounds good. I might add a config object. Thanks!