Refactor SocketIORouter
Add a server-side changeset queue per pad

fixes #1573
Don't block changeset queue with delivering changeset
Fix authorship sanitization

author colors wouldn't get disttributed, if their id was greater than 9
(due to apool encoding them to base 36)
Remove console.log in content collector

fixes #1731
IE8 complains, if catch block is missing
IE8 don't knows the Array.forEach function (simple version fix)
use document, not doc
Merge pull request #1750 from ether/fix/authorship-once-and-4-all

Fix authorship sanitization
fixed spacing
dont crash on no auth, ust a bandaid
Merge branch 'feature/add-cs-queue' of github.com:ether/etherpad-lite into dont-crash-noauth
better message for admins
Just a missing character
Merge pull request #1754 from goldquest/patch-1

Just a missing character in README
Localisation updates from http://translatewiki.net.
Update SocketIORouter.js

Changed the setting of client.remoteAddress
updated to use settings

updated handler/SocketIORouter.js to use new setting
updated hooks/express.js to use new setting
updated utils/Settings.js to accept new setting
updated settings.json.template so new setting is present
Issue #1625: Fix to client-side-induced changeset spamming.

THE BUG - HIGH LEVEL:
- When client A sends out an attribute change, client B applies that change to itself but
  also thinks that it made the change itself, which is incorrect. This means that when client B
  next makes a change, he will send out that he made the attrib change that A actually made.
- Ex: Have 2 clients on the same pad. Have A apply bold on some text. Next, have B type a character.
  B will broadcast that it both added a character AND applied bold, when in reality it did NOT
  apply bold at all, that change was done by the other client and this client incorrectly adopted it as its own.
- This root bug behavior results in clients continuing to think that they each made the other client's change,
  thus resulting in an infinite loop of changeset spamming that bogs down clients and harms server stability.

THE BUG - IN DEPTH:
- The root issue is in the way that Changesets are combined in Changeset.follow(). Specifically, in the case of a
  changeset with ONLY new attrib changes (no text changes) being merged with an identity changeset (has no ops).
- In this case, Changeset.follow() copies the ops of the new CS and fully overrides the other CS.
- applyChangesToBase invokes Changeset.follow to determine the final client document CS state after applying the new CS.
  If the final client document CS state is NOT the identity CS, then the client broadcasts that it made a change.
- When client A changes just attribs, client B's applyChangesToBase calls Changeset.follow() and passes client A's
  changeset (attrib change) and Client B's current changeset state (identity).
- As per the noted bug, Changeset.follow() returns client A's changeset as a result, causing client B to adopt
  client A's changeset as its own document state. Thus, client A ends up thinking it has made client B's changes.

THE FIX:
- Changeset.follow() should NOT copy the ops of the new CS passed in if those changes are only attrib changes.
  This allows applyChangesToBase to properly set the client's CS back to the identity after applying an
  external attrib change, instead of incorrectly adopting the external client's changes.
Add a server-side changeset queue per pad

fixes #1573