Implement roaring64_bitmap_internal_validate

[Dr-Emann]

Add calls to validate the bitmap around the unit tests

[lemire]

Either here or as part of another PR, we should add this to our fuzzer...

https://github.com/RoaringBitmap/CRoaring/blob/master/fuzz/croaring_fuzzer.c

[SLieve]

Given what the docs describe, I feel that there is some slight mismatch with what we do in roaring64_bitmap_portable_deserialize_safe, because there we construct 32-bit roaring bitmaps and, importantly, don't call internal_validate on them. Not sure what the best solution is here.

[Dr-Emann]

That's a good point. I think the way we interact with those bitmaps is safe (at least for now):

• we don't do anything with the containers themselves
• roaring_bitmap_portable_deserialize_safe will always return a consistent count of containers (if the bitmap says it has N containers, there should be N keys, typecodes, containers)
• we don't (currently) rely on the container keys being ordered
  • This does mean we could create a valid roaring64 bitmap from an invalid serialization (if a sub-bitmap serialization had unsorted keys, we'll end up with them in the right place because we insert them individually into the ART)
• freeing the bitmap must always be safe

It does mean that, like roaring_bitmap_portable_deserialize_safe, despite the name containing "safe", it's absolutely possible to get a segfault interacting with the returned roaring64 bitmap if you feed it junk unless you call validate on it (or have external proof that the input is validly the output of serializing a roaring64 bitmap)

[SLieve]

That's a fair assessment, we can leave the wording as-is then.