Updated Google Analytics

* Universal Google Analytics tracking
* Removed CRLF line endings
Removes pooling of kernel transactions

as well as whatever instances kernel transactions contains, like lock
clients. This fixes an issue of unknown root cause, causing locks to get
stuck in some scenarios.
Extra nodejs note for Debian/Ubuntu.
Add projectFreshSortExpressions rewriter
Last committed transaction refers to last forcefully appended to log

There was a race condition where
TransactionIdStore#getLastCommittedTransactionId() might return a
transaction id higher than existed in the log on disk, actually even even
before even appended to the log buffer. This resulted in a temporary
condition where a thread would query for last committed transaction id and
then try to retreive those transactions and would fail with an exception
saying that the requested transaction didn't exist.

So this commit introduces a phase before 'committed' which is 'committing'
and those are marked as committed when they have been forcefully committed
to the log. So TransactionIdStore#getLastCommittedTransactionId() method
name is unchanged, but its behaviour is changed to return the last
(highest) truly committed transaction, not the last committing.
Merge pull request #2931 from tinwelint/2.2-remove-tx-pooling

Removes pooling of kernel transactions
Merge pull request #2909 from simpsonjulian/new-google-analytics

Updated Google Analytics
Merge pull request #2956 from tinwelint/2.2-next-and-applied-tx-window

Last committed transaction refers to last forcefully appended to log
Further dismantle inlineProjections

It no longer produces WITH * clauses, the reason being that they
were making it harder for the planner to reason about arguments
that need to be fed into a tail planner query.

Instead, the planner query builder will squash two planner queries
together if the intermediate projection is a simple identifier
to identifier mapping.
Merge pull request #2947 from nigelsmall/readme-tweak-for-ubuntu

Extra nodejs note for Debian/Ubuntu.
Merge pull request #2955 from jakub-/fresh-name-rewriters

Fresh name rewriters
Store application ordering of transactions w/ legacy index changes

Only a single transaction at a time can append to the log buffer, but
multiple transactions can apply changes onto the store simultaneously in
2.2. For graph and schema indexing changes there are the high level
entity locks that guarantee correct ordering of transactions wanting to
change the same records. However for legacy indexes there are no such
ordering. This might result in for example an REMOVE+ADD turning into a
ADD+REMOVE, i.e. two different end results.

So, this commit introduces ordering of transactions making any legacy
index changes so that such transactions gets applied in the same order
as they were appended to the log. Transactions that doesn't change
any legacy indexes will not be ordered like this and will pay no cost
whatsoever for the ordering introduces here.

This commit also adds apply() to NeoCommandHandler such that
CommandApplierFacade can call a round of apply() to all appliers and the
another round of close(). This fixes an issue where store application
locks would be released too soon.
Previously:
  * apply graph changes
  * release graph update locks
  * apply schema index changes
  * apply legacy index changes

Now:
  * apply graph changes
  * apply schema index changes
  * apply legacy index changes
  * release graph update locks