Tighten memory constraints for cram_decode.

SAM aux tags have code [A-Za-z][A-Za-z0-9].  Our content ids also
include the type, but we can't have the same code with more than one
type.  So the maximum number of tags possible is 3224.  Each code
could be using multiple blocks (eg via byte-array-len), and we have
other blocks too for the fixed fields, but a maximum of 10,000
possible blocks in any slice is a generous upper-bound.

This avoids memory issues with files where num_content_ids is 100s of
millions.  We already blocked memory wrap-around and malloc woes, but
it's safer to be more restrictive.  This also fixes out-of-memory
errors in fuzz testing.

Credit to OSS-Fuzz
Fixes oss-fuzz 61840

cram/cram_decode.c

@@ -1000,9 +1000,9 @@ cram_block_slice_hdr *cram_decode_slice_header(cram_fd *fd, cram_block *b) {
     hdr->num_blocks      = fd->vv.varint_get32((char **)&cp, (char *)cp_end, &err);
     hdr->num_content_ids = fd->vv.varint_get32((char **)&cp, (char *)cp_end, &err);
     if (hdr->num_content_ids < 1 ||
-        hdr->num_content_ids >= SIZE_MAX / sizeof(int32_t)) {
-        /* Slice must have at least one data block,
-           and malloc'd size shouldn't wrap. */
+        hdr->num_content_ids >= 10000) {
+        // Slice must have at least one data block, and there is no need
+        // for more than 2 per possible aux-tag plus ancillary. 
         free(hdr);
         return NULL;
     }