r64 iterator: allow moving from beyond the start / end

[SLieve]

Fixes #574.

Previously calling roaring64_iterator_previous after roaring64_iterator_advance returned false would not move the iterator. With this commit, this behavior and its inverse are both possible.

I chose to implement this by adding a new field in the iterator to indicate saturation. Another option would be to allow the ART iterator to allow moving from beyond the start / end, but that would require changing the index to a signed integer and thus take up more space.

[Dr-Emann]

@SLieve I believe with this implementation, it is safe to call roaring64_iterator_advance after the iterator has already reached the end (and vice-versa) unlike what the documentation says:

CRoaring/include/roaring/roaring64.h

Lines 601 to 602 in cf56e66

	* Once this returns false, `roaring64_iterator_advance` should not be called on
	* the iterator again. Calling `roaring64_iterator_previous` is allowed.

Is this something we want to document, or is it better to leave it open to allow us to make it unsafe in the future? (Personally, in the rust bindings, I'm currently keeping track of "which end did we last go over" as well, and it would be nice to avoid having to keep that extra state if we're willing to guarantee it's safe to do so.)

[SLieve]

For consistency across the API I would lean toward disallowing it (as we disallow it in the 32-bit version), but I don't feel strongly. Alternatively we can also make it safe in the 32-bit version, which sounds nice.