Clarify In-Place operation semantics

Been fooling around with optimizing in-place operations, in particular if we can do better with run containers. My interest is in solutions that are performant both in terms of calculations and allocations. Right now, the semantics for container calls like ior() and iand() are not well specified. They always return a container, that container will always be the union/intersection and it will usually, but not always, be the receiving struct. This ambiguity is mainly handled by always using the returned value, such as at https://github.com/RoaringBitmap/roaring/blob/master/roaring.go#L731 or https://github.com/RoaringBitmap/roaring/blob/master/roaring.go#L554. However, in at least one place we perform a naked ior(), which breaks if the underlying container is not updated with the union result.

My suggestion is to change the semantics so that iand() etc. return nil when the container was actually updated in-place, and a non-nil result value when it wasn't. The downside is that the code would be slightly more verbose. For example, instead of

c1 := rb.highlowcontainer.getWritableContainerAtIndex(pos1)
c2 := x2.highlowcontainer.getContainerAtIndex(pos2)
diff := c1.iand(c2)
if !diff.isEmpty() {
	rb.highlowcontainer.replaceKeyAndContainerAtIndex(intersectionsize, s1, diff, false)
	intersectionsize++
}

it'd be

c1 := rb.highlowcontainer.getWritableContainerAtIndex(pos1)
c2 := x2.highlowcontainer.getContainerAtIndex(pos2)
diff := c1.iand(c2)
if diff == nil && !c1.isEmpty {
        intersectionsize++
} else if !diff.isEmpty() {
	rb.highlowcontainer.replaceKeyAndContainerAtIndex(intersectionsize, s1, diff, false)
	intersectionsize++
}

The main advantages are that it would be more explicit and not have to always reset the value in the bitmap.

It'd be a good piece of work to refactor everywhere, so figured I'd get feedback first.

Start by reading the container operations around ior() and iand(), then inspect the call sites in roaring.go and fastaggregation.go, including the naked ior() call. Compare how each caller handles returned containers and determine the complete refactoring scope. Done means the semantics are consistent across all call sites and in-place updates cannot be missed.