Currently, the UI authenticates with the server using two parallel methods:

* A cookie set by the `/api/auth/login` endpoint.
* A token returned by the same endpoint.

This is redundant and confusing, and also causes several usability &
security issues:

* If a user creates 2 or more concurrent sessions (e.g. logs in on two
  computers), and then logs out of one of them, it will effectively log
  them out of all other sessions too. This happens because:

  1. The same token is shared between all sessions.
  2. Logging out destroys the token in the DB.
  3. The server tries to authenticate the browser using the token first,
     so if a browser presents a token that's no longer present in the DB,
     the server responds with a 401 (even if the cookie is still valid).

* When a user changes their password, Django invalidates all of that user's
  other sessions... except that doesn't work, because the user's token
  remains valid. This is bad, because if an attacker steals a user's
  password and logs in, the most obvious recourse (changing the password)
  will not work - the attacker will stay logged in.

* Sessions effectively last forever, because, while Django's session data
  expires after `SESSION_COOKIE_AGE`, the token never expires.

* The token is stored in local storage, so it could be stolen in an XSS
  attack. The session cookie is not susceptible to this, because it's marked
  `HttpOnly`.

The common theme in all these problems is the token, so by ceasing to use it
we can fix them all.

Note that this patch does not remove the server-side token creation &
authentication logic, or remove the token from the output of the
`/api/auth/login` endpoint. This is because that would break the
`Client.login` method in the SDK. However, I believe that in the future we
should get rid of the whole "generate token on login" logic, and
let users create API tokens explicitly if (and only if) they wish
to use the SDK.