Improve the error message for MERGE statements with map property parameters.

This case cannot be supported because the MERGE can't be planned without
knowing the properties involved, but they are hidden away in the parameter map.
Clean up, mostly of silly useless TODO comments.

Mostly by removing useless comments, but also removed the CircuitBreaker.
The CircuitBreaker was removed because it was not used anywhere in our
code, and everything under org.neo4j.kernel is private API, so deleting it
is safe since clients can only depend on it at their peril.

I left the FinalTraversalBranch class stay, even though it too is really
suspect. The only place where it is used is obviously broken, and might not
even be used. I might do more research to look into this, to see if it too
can be removed, or if we actually wanted to use it for something.

Also removed an unused method in NodeStore that I came across.
Remove FinalTraversakBranch.

Also remove the obviously broken method that used it.
Brokeness b'gone.
Removed lock striping when loading nodes/relationships

Previously, loading a node or relationships had the loading code wrapped in a lock, striped on the key
where there were an arbitrary number of stripes. The lock would prevent multiple threads to load the
same entity at the same time, or more specifically prevent multiple threads to put two versions of the
same entity into the cache at the same time.

So without the lock there can be thread T1 loading an entity into an entity object E1 at the same time
as thread T2 loading the same entity into another entity object E2. E1 and E2 represent the same entity E.
This race would have one of the threads win and have its version put in the cache last,
the other overwritten. Consider the similarities of that race with cache eviction coming into play,
where T1 loads E1 and puts it in cache and returns it. After that and before T2 comes in
and wants that same entity there has been an eviction of E1. T2 would then load E2 and
put into cache resulting in two "live" versions of E. It seems that having the lock would merely
reduce the chance for this happening, not prevent it.

There doesn't seem to be any reason as to why having two versions of the same entity object would cause
problems (keep in mind that there will only be one version in the cache).
Also, the overhead of locking grows with the number of threads/cores to eventually become a bottle neck.

Based on that the locking was removed.

co-author: Johan Svensson, @johan-neo
extracted RepresentationDispatcher and specialized it for Cypher
nested maps coming out of cypher are now rendered as proper/ roundtripable json
RestRepresentationWriter no longer outputs "data: {...}" in front of serialized maps. if the user constructs free-form maps in their query they will not need them to look like "subsets" of nodes or rels.
matching iterables instead of lists in RestRepresentation, and giving Paths a chance to fire first
Merge pull request #1196 from chrisvest/cleanup

Cleanup
Merge pull request #1202 from tinwelint/2.0-no-lock-striping

Removed lock striping when loading nodes/relationships
Merge pull request #1194 from benbc/2.0-merge-map-parameters

Improve the error message for MERGE statements with map property parameters
Revert "Removed lock striping when loading nodes/relationships"

This reverts commit a80c2a8bc51d2ab592c01a898c6ad30bcad52391.

Some changes are required to have this fully work
Platform-independent line separators.
Allow decimals without leading 0 (ie. ".5")
Merge pull request #1206 from lassewesth/literalmaps

literal maps: surface area fixes
Merge pull request #1211 from cleishm/ugly_decimals

Allow decimals without leading 0 (ie. ".5")
Constraint creation in HA clusters.

 o To protect from race conditions between constraints coming online on master long before they are enforced on slaves,
   master now rejects transactions that were started before a constraint was brought online.

 o This initial implementation does not verify if these started-before transactions fail the new constraint, it simply
   fails all. The reasoning here is that the window for this is a few milliesconds to a second, and it will only occur
   when an admin has manually brought a constraint online. As such, it felt uneccessary to duplicate the constraint
   validation code.