Move neo4j server to Jetty 9
Tagging for version 2.0.0-M05
BatchInserter support for LabelScanStore

on a clean shutdown the batch inserter populates the selected label scan
store. It's doing so in the same store scan as the one populating all
schema indexes. For that NeoStoreIndexStoreView changed to support one
property update visitor and one label update visitor and invites them both
for a single store scan.

Introduced a NeoStoreProvider which take on the same role in the batch
inserter case as XaDataSourceManager does in the GDS case. A label scan
store may need to access the NeoStore as a dependency and the actual
NeoStore instance isn't guaranteed to exist at startup or when the label
scan store (via an extension) is initialized.
Back to development version.
Updated the change logs
Merge pull request #1148 from jakewins/2.0-jetty-9

Move neo4j server to Jetty 9
Merge pull request #1164 from tinwelint/2.0-batch-insert-label-scan

BatchInserter support for LabelScanStore
Removed breaking change from changelogs, since the change never happened.
Removed PropertyData (the old property representation)

The move of property handling to the kernel API isn't fully done. One
aspect of that "incompleteness" is that we've get the old PropertyData
class hierarchy, while using a new very similar Property class hierarchy
in new code in the kernel API. PropertyData had one #getId() method that
Property doesn't, but that wasn't used anywhere.
Represents tokens (label/prop key/rel type IDs) as ints instead of longs

This commit only changes the in-memory representation, not any store
format.

Known store constructs still storing tokens as if they were longs:
 o IndexRule propertyKey
   from the outside it now looks like it's an int, but putting/getting
   to/from the ByteBuffer uses putLong/getLong
 o NodeLabelsField
   even from the outside it looks like longs. This is mostly due to the
   wat we decided to piggy-back on the long[] labels array, where we put
   the node id (which is a long) into that array as the first element.
   Converting this to an int[] externally would incur more array copying
   back and forth between int[]<-->long[] there.
 o HA protocol Master#acquireIndexEntryWriteLock still uses long for
   labelId/propertyKeyId to not change the protocol.
 o There might be more...