Create new format for the (Lucene) LabelScanStore.

The NodeRangeDocumentLabelScanStore overcomes the 2B document limitation in Lucene
by storing information about labels for multiple nodes in each Lucene document.

Each lucene document represents a range of 32 or 64 (configurable) nodes with same high order bits.
Each document contains a field for each label that any node in the range has. The value of the field
is a bitmap with a bit set for each node in the range that has that label present.
Adds the ability to do label scan search as a Term Query.

Potentially this is more efficient than using Range Queries to emulate "key presence" queries.

This is done by having a separate field that is indexed only (not stored in the document) for searches,
and then not indexing the bitmap field. So storage wise, this implementation should be about the same.
Although it is possible that both in terms of storage overhead, and query efficiency having multiple
different indexed fields is sub optimal, in which case this implementation would be better.
This is to be determined by benchmarks.
Use the NodeRangeDocumentLabelScanStorageStrategy.
Fixes some problems with node range representation

o Updates to lucene index was made in batches, but after a flush there was
  no "refresh" of the searcher, so some updates was lost the next time the
  same document was updated again.
o the wrong field was used to discover how many hits a TopDocs result had.
  It worked for the first query, but not consecutive "page" queries.
long->int storage optimization for 32-bit bitmap format

so that the lucene index may take up less space also made
BitmapDocumentFormat into an enum with the same values as BitmapFormat
and then pulled in the format used in SearchAcceleratedBitmapDocumentFormat
since it always came out best in performance tests.
Merge pull request #1314 from tinwelint/2.0-better-label-scan

LabelScanStore implementation that scales up to 137 billion labeled nodes