New signer token RPC & Initial signer connection without token.

[tomusdrw]

1. personal_generateAuthorizationToken RPC method available only over Signer's WebSocket connection.
2. When there are no tokens generated (store is empty = i.e. first run) single WebSocket connection will be allowed to access using special token with value initial.

Closes #1999

[jacogr]

General question around functionality -

1. User opens (new) UI is Chrome, takes him/her through the setup process, the token gets generated and stored in localStorage. Everything all ok, seamless.
2. User opens UI in FireFox (or extension) - what happens? Browser store is empty since it doesn't have a token, but... Any issues?

[tomusdrw]

Yes, so the second signer should ask for authorization token, which can be generated:

1. Via CLI (as currently)
2. Via previously authorized Signer (using personal_generateAuthorizationToken RPC endpoint)

[coveralls]

Coverage increased (+0.1%) to 85.206% when pulling 63d7ffb on signer-initial into c8533a3 on master.

[rphmeier]

is there an indication that this is in fact enough time for all requests to be handled? Spurious test failures caused by a too-short timeout would be annoying.

[tomusdrw]

So there are no requests that are doing any heavy stuff, but of course there is no guarantee that all of them will be handled.
Unfortunatelly it's necessary for some other requests that are not closing the connection after replying with a handshake (i.e. websocket upgrade requests).

I didn't have any other idea how to handle those - read without timeout blocks idefinitely, setting non-blocking mode returns WouldBlock on every try, tbh I have no idea why I cannot just read a handshake and then close the connection (Same thing happens if http server is trying to keep the connection alive (i.e. Connection: close header is missing))

I'm open to any ideas.