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.

- 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.
- Constraint enforcement using unique indexes have now been collected in the
  ConstraintEnforcingEntityOperations part of the cake, which means that
  StateHandlingStatementOperations, CacheLayer and DiskLayer now no longer need
  to concern themselves with unique indexes -- to them it's all just indexes
  now.
- Tons of tests have been updated to match and verify these new behaviours.