Fix bug with precision loss on indexing large numbers.

The problem was that we always coerced numbers to doubles, when encoding
their value in the index. This means that the loss of precision could cause
large long values that was sufficiently close together, to coerce to the
same indexed values. When this happened, index lookups would return
incorrect results by finding too much data, and constraints would be overly
restrictive. This has been fixed by double-checking the actual values in
the store, and filter out non-exact matches.

We could have alternatively changed the way that we store numbers in the
indexes, however, this would have introduced a store format change. We
decided against this solution since we just had a bunch of store format
changes in 2.0, and we did not want to burden our users with another one
in a bug-fix/patch release.

- When the DeferredConstraintVerificationUniqueLuceneIndexPopulator finds
  a collision in the index, it now looks up the actual value from the store,
  and double checks that the values are actually colliding, before claiming
  that a duplicate entry has been found.
- The UniqueInMemoryIndex does a similar thing.
- To help the indexes do lookups in the store, they are now being given a so
  called PropertyAccessor, which is implemented by the NeoStoreIndexStoreView
  class, which is provided by the IndexPopulatingJob.
- IndexPopulators are now given an IndexDescriptor for the index they are
  populating, so that they can get at the propertyKeyId for doing their
  property lookups throught the PropertyAccessor.
- The equality semantics of BooleanArrayProperty has been changed to be more
  similar with the other array property types. This was important because
  empty arrays are always equal to other empty arrays, regardless of the
  component type.
- The ListBasedIndex (an InMemoryIndex implementation type) is now gone, and
  the HashBasedIndex is now the default InMemoryIndex implementation, because
  it was easier to implement the new verifyDeferredConstraints method using
  the HashBasedIndex.
- ArrayEncoder no longer needs the ability to decode indexed values, because we
  now read the real values from the store.
- The SchemaProviderApprovalTests that already existed for indexes have been
  duplicated and modified so we now also verify the behaviour of constraints.
- The index look-up mechanisms have been streamlined throughout the DiskLayer,
  CacheLayer and StateHandlingStatementOperations.
- ConstraintEnforcingEntityOperations is virtually untouched by these changes.
- Tons of tests have been updated to match and verify these new behaviours.