make /devices return a list

Turns out I specced this to return a list of devices rather than a dict of them

Implement GET /device/{deviceId}

Preserve device_id from first call to /register

GET /devices endpoint

device_id may only be passed in the first call to /register, so make sure we
fish it out of the register `params` rather than the body of the final call.

(pick up PR #938 in the hope of fixing the UTs)

Record device_id in client_ips

Register a device_id in the /v2/register flow.

implement a GET /devices endpoint which lists all of the user's devices.

It also returns the last IP where we saw that device, so there is some dancing
to fish that out of the user_ips table.

Record the device_id when we add a client ip; it's somewhat redundant as we
could get it via the access_token, but it will make querying rather easier.

Fix some more comments on some things

This doesn't cover *all* of the registration flows, but it does cover the most
common ones: in particular: shared_secret registration, appservice
registration, and normal user/pass registration.

Pull device_id from the registration parameters. Register the device in the
devices table. Associate the device with the returned access and refresh
tokens. Profit.

Add metrics for psutil derived memory usage

Don't notify pusher pool for backfilled events

Type annotations

Further registration refactoring

Feature: Add filter to /messages. Add 'contains_url' to filter.

Add some type annotations to help PyCharm (in particular) to figure out the
types of a bunch of things.

* `RegistrationHandler.appservice_register` no longer issues an access token:
  instead it is left for the caller to do it. (There are two of these, one in
  `synapse/rest/client/v1/register.py`, which now simply calls
  `AuthHandler.issue_access_token`, and the other in
  `synapse/rest/client/v2_alpha/register.py`, which is covered below).

* In `synapse/rest/client/v2_alpha/register.py`, move the generation of
  access_tokens into `_create_registration_details`. This means that the normal
  flow no longer needs to call `AuthHandler.issue_access_token`; the
  shared-secret flow can tell `RegistrationHandler.register` not to generate a
  token; and the appservice flow continues to work despite the above change.

rest/client/v2_alpha/register.py: Refactor flow somewhat.

Add device_id support to /login

This is meant to be an *almost* non-functional change, with the exception that
it fixes what looks a lot like a bug in that it only calls
`auth_handler.add_threepid` and `add_pusher` once instead of three times.

The idea is to move the generation of the `access_token` out of
`registration_handler.register`, because `access_token`s now require a
device_id, and we only want to generate a device_id once registration has been
successful.

device_id should be text, not bigint.

Update docstring on Handlers.

To indicate it is deprecated.

Add a 'devices' table to the storage, as well as a 'device_id' column to
refresh_tokens.

Allow the client to pass a device_id, and initial_device_display_name, to
/login. If login is successful, then register the device in the devices table
if it wasn't known already. If no device_id was supplied, make one up.

Associate the device_id with the access token and refresh token, so that we can
get at it again later. Ensure that the device_id is copied from the refresh
token to the access_token when the token is refreshed.