estargz: parallelize MinChunkSize builds

[simonepri]

Builds with MinChunkSize > 0 run on a single core, no matter how large the layer is.

They are serial because the writer maintains one invariant -- every gzip stream except the last holds at least MinChunkSize compressed bytes -- and does so by placing each stream boundary based on the compressed size of everything written before it.

The build can be parallelized while preserving the invariant as long as:

• each worker's slice of the tar holds at least MinChunkSize * 1032 uncompressed bytes (1032 is DEFLATE's maximum compression ratio), so every slice fills at least one full stream;

• the trailing stream of a slice, which usually ends below the minimum, is folded into the stream before it. The writer now withholds a full stream's terminator until the next stream also reaches the minimum, and folds the tail back by replaying its buffered raw bytes. Only the short tail is ever recompressed.

After this change the invariant also comes out stronger: the trailing stream of the whole blob, previously allowed to end short, is folded as well. A stream now ends below MinChunkSize if and only if the data itself is smaller (or a prefetch landmark forces a boundary).

Note that with this change MinChunkSize layer digests differ from previous releases: large layers build in parallel (the layout depends on GOMAXPROCS, like every other eStargz build) and trailing short streams are folded away. eStargz makes no cross-version byte stability promise.

[simonepri]

@ktock since you implemented the serial version of this, could you take a look.
The idea is that once #2341 lands then user would be able to go back to the previous implementation (modulo the last chunk being still merged back) by setting parallelism to 1.

[simonepri]

@AkihiroSuda @ktock friendly ping

[simonepri]

@ktock rebased this on main again after the --parallelism flag merge