Improve checking of *out_size in rans4x16 & arith

[jkbonfield]

These should be set to a minimum of at least rans_compress_bound_4x16() or arith_compress_bound() but as they're user supplied parameters we ought to consider the possibility of them being smaller and the potential for an encode failure. (Although arguably it's a user error too as we're not using the API as intended.)

This happens in many places, but not consistently when very small sizes are given such that we don't have room for the compression header meta-data.

[jkbonfield]

Another round of updates squashed in. I expect there may be issues with other codecs too, but we don't have to solve every problem in every PR. This focuses only on the CRAM 3.1 rans and arith coders.

I have a (not committed as it's hacky) little test which constructs (ABAC)* repetition and then permits me to compress using various "order" options, with manually specified ranges of out_size buffers. Note this is NOT how the API is meant to work. You should call the appropriate function (eg arith_compress_bound) with an input buffer size and the order byte and it'll give you the worst case size of memory needed to compress the data, and it's up to you to ensure you provide a buffer that big.

We do just that in all our use cases, so this is not a bug anywhere for htslib, samtools, etc. However if you're a trouble maker and allocate a buffer too small then we now bail out correctly. Obviously you can still allocate it too small and say it's larger in which case it dies, but that's no different than lying to memcpy etc. Both are API usage errors, but the former at least should have some chance of spotting memory errors before they happen as we've told it how big our (undersized) buffer was.

[jkbonfield]

Somewhat unrelated, I also changed it to always return out_size=0 when failing, as well as returning NULL. I don't know if that's useful or not, but it seemed tidier. It's neither here nor there I guess.