As requested: this enables support for Roaring Bitmap with minimal code duplication

Recall that we believe that Roaring Bitmap can have benefits over ConciseSet. See http://roaringbitmap.org/ for documentation. The API (Javadocs) is available online: http://lemire.me/docs/RoaringBitmap/

We initially proposed to add support for Roaring bitmaps by duplicating classes. Though functional, this approach did not seem to generate much enthusiasm.

This new pull request offers minimal code duplication. The same code supports both  ConciseSet and RoaringBitmap through wrapper classes (that are part of a separate package included in this pull request) derived from abstract classes. The main code has been gently modified to work over these abstract classes instead of the ConciseSet classes.


The changes to the original code are minimal but do require the use of a BitmapFactory by which we stipulate whether we use ConciseSet, RoaringBitmap or something else. So this adds a little bit of complexity (typically an extra line of code and an extra object here and there). Sadly this means that the number of lines of code that have been added or modified is rather high. This was unavoidable but we tried to keep it as small as possible.

It goes without saying that the unit tests have been extended to cover both ConciseSet  and RoaringBitmap. 

I should stress that, by design, these wrapper classes are minimal by design and what they achieve is just what is needed here, no more. Though one may wish that by flipping a switch we could go from ConciseSet to  RoaringBitmap and back, this cannot be possible. These are totally different libraries written entirely separately with vastly different ideas (different data layouts, different algorithms). There are unavoidable API differences that must be accounted for... and testing must be separate.

Please get in touch with me if there is any issue you need resolved.
looks like this can easily be changed to be an interface instead of abstract class.