Avoid unnecessary heap allocations

[lemire]

Generally, CRoaring does far too many heap allocations. This slows down the code in some instances, and it can make it more fragile.

In many instances, especially when computing intersections, we generate empty containers that are immediately garbage collected.

There are clever tricks we could use to start scanning the input containers, advance up to the point where there might be values to be intersected, and bail out without generating an empty container if the intersection is empty.

[haudan]

Can we expand this issue to the constructor functions like roaring_bitmap_t *roaring_bitmap_create(void);? I don't think these functions need to allocate the object. Changing the signature to void roaring_bitmap_create(roaring_bitmap_t *bitmap); allows the user to allocate the bitmap on the stack, instead of forcing them to allocate it on the heap.

[lemire]

Makes sense to consider the larger issue.

[stdpain]

@lemire Hi, I noticed that the sizeof array_container_t bitset_container_t run_container_t is not bigger than 16. Can we consider allocating these objects together instead of using malloc separately?

eg:

roaring_array_t ra;
ra.size = 1024;
ra.containers = malloc(ra.size * 16);
ra.type = xx// init types
for(int i = 0;i < ra.size; ++i) {
	if (ra.type[i] == ARRAY_CONTAINER_TYPE_CODE) {
		array_container_init(&ra.containers[i]);
	} else if () ....
}

[Oppen]

@stdpain this and other alternatives are discussed in #5 I invite you to write any ideas there :)