Add support for managing multiple stream subscriptions in a single connection

[Gargron]

There's 0 reason to need to open 10 different websockets connections for user stream, public timeline and 8 different hashtags. Multiplexing all streams over a single connection will reduce load on both ends and make receiving live updates from newly opened timelines feel less sluggish.

The changes are as follows:

• OAuth scopes are no longer checked when the WebSocket connection is established, instead, they are checked when a subscription to a specific stream is requested
• The stream requested through the URL when establishing the WebSocket connection is processed immediately, but unlike before, insufficient scopes do not close the connection
• A missing access token will no longer close the connection immediately unless the server is running in limited-federation or secure mode (though an invalid access token will still do)
• The client can send a JSON payload like { "type": "subscribe", "stream": "hashtag:local", "tag": "foo" } over the WebSocket connection to subscribe to a new stream
• A JSON payload like { "type": "unsubscribe", "stream": "user" } over the WebSocket connection will unsubscribe from a previously subscribed stream
• A new property on the transmitted events will refer to the stream it was transmitted for: stream, formatted as an array like ['user'] or ['list', '1234']. This property only appears on WebSocket connections.

[ClearlyClaire]

I understand why this is done, and it should work, but I personally find using mutable variables inside closures pretty confusing. I wonder if there's a less confusing way to go about it that is as concise.

[Gargron]

This isn't different to how it was managed before just in a different place.

[ClearlyClaire]

ok this is a fairly large change so I'm not 100% confident with my review, but it looks good to me