[lemire]

Some operations that modify a bitmap, such as AddRange and RemoveRange, do not always convert a run container back to an array or bitmap container when the runs stop being the most compact encoding. In the worst case, the runs of one 65536-value chunk take about 128 KiB where a bitmap container takes 8 KiB. Calling RunOptimize again recovers that space. This is the Go counterpart of RoaringBitmap/RoaringBitmap#886. See also RoaringBitmap/RoaringBitmap#879.

Measured on master:

Case	Serialized bytes before RunOptimize	After
Full chunk, then RemoveRange(i, i+1) for every even i	131,083	8,208
AddRange(0, 100), then AddRange(i, i+1) for every even i from 200	130,687	8,208
Same RemoveRange case with roaring64	131,095	8,220

Single-value Add and Remove already keep containers minimal, so the documentation does not name them.

Changes

• Doc comments of RunOptimize on roaring.Bitmap and roaring64.Bitmap, and on both BSI types, which refer to Bitmap.RunOptimize.
• README: a paragraph after the serialized-size bound.
• A test in both roaring and roaring64 checking that RunOptimize shrinks such a bitmap more than tenfold without changing its contents.

go test ./... passes and gofmt is clean.