Textual error codes

This makes the error codes returned from the "transactional endpoint" of
the HTTP API be strings. String error codes has several benefits over
numeric error codes. Textual error codes are more descriptive and easier
to search for. Textual error codes also support both classification and
categorization, numerical error codes can only support either one or the
other.

Classification would be the distinction between transient and permanent
error conditions for example. Categorization would be the distinction
between different error sources (client side or server side), and
between different types of error (syntax errors, transaction errors,
et.c.).
Name spaces for Status code definitions.

Declares a separate enum for each Category of error statuses.
Specific Status codes for Cypher exceptions.
Don't roll back transaction on ClientError.
Merge pull request #1385 from thobe/2.0-textual-error-codes

Textual error codes
Remove randomness in BitmapFormatTest.

The randomness could generate bad input (negative numbers), which would
fail the test at occasionally. Instead iterate over all possible
permutations, the space of possible combinations is small enough.
Consistency checker: check that nodes are indexed.

o Directly use PropertyStore instead of the RecordAccess API
  to reduce code duplication at the expense of deferred check mechanism.
  This could prove to be an expensive check because of the need to read
  whole property chain for each node.
o Add parameters for turning off label scan store and index checks.
o Check uniqueness of unique indexes.
o Keep index accessors open for duration of entire consistency check.
o Extract tasks into their own class.