Annotation card & groups list style cleanup

Move /api/token endpoint into application

Using @extend with a class declared in a different source file
prevents local reasoning about the final set of rules
that will apply for a class because that depends on
what order the components are included.

See http://csswizardry.com/2014/11/when-to-use-extend-when-to-use-a-mixin/
for additional reasons to avoid @extend in most cases.

 * Make the .scss file names consistent with the names
   of their components for <annotation>, <thread>
   and <markdown>.

 * Sort component includes alphabetically and use relative
   paths. Although SASS technically doesn't care about
   relative paths, it makes the code style more consistent
   and also provides consistency with the JS code.

 * Move app-specific component style includes out of
   common.scss into app.scss

Rename style to signin-control-menu to match
the name of the associated component.

Move styles for the <group-list> and <signin-control>
components out of app.scss and into the appropriate
SCSS files.

Do not clear selection and reset search when creating a reply

Don't open "welcome page" when installed by admin policy

The purpose of clearing the selection was to ensure
that the new annotation was immediately visible.

Clearing the selection when creating a reply to
a selected annotation is not necessary because the reply
is part of an already-visible thread.

The logic for clearing the selection and search in the sidebar
when creating a new annotation was incorrectly being triggered:

 a) On the stream, where creating new annotations
    is not possible except for replies and
 b) For replies. The selection should only be cleared in the sidebar
    when creating a new annotation with a location on the page.

This commit addresses the first issue by moving the logic
for clearing the selection to the sidebar's controller.

Upgrade to Angular 1.5.0

Angular 1.5 introduces '<' as a way of specifying
that an isolate scope property is an input (one-way) binding.
Note that this is different from '::' (one-time) bindings from
ng 1.3.

See http://angularjs.blogspot.co.uk/2016/02/angular-150-ennoblement-facilitation.html
for details.

The principle benefit is making it obvious when looking
at the definition of a component whether a property is an input
or whether it is a binding that the component might write to.

The only change required was to fix an issue in <excerpt>
where the optional 'animate' and 'collapse' properties
were not correctly marked as optional, triggering
an internal error.

Annotation test cleanup

Scrollable groups list

This commit ensures that the groups list is scrollable when it is forced
to be smaller than the viewport due to the number of groups in it.

It's not an ideal solution, as in some contexts there isn't much of a
hint to the user that the widget is scrollable. It probably beats the
existing behaviour, though.

Fixes #2971.

I'm about to use this in a calculation elsewhere.

Angular's documentation for inject() involves a bunch of silly
boilerplate. This adds a utility function which wraps the inject()
function to provide a less verbose way of getting at ng modules
in tests.

Also make all of the fixtures pure functions and move
the logic for setting up the drafts fake into the
createDirective() function in the annotation tests.

Where a fake service/filter is not accessed directly
by any tests, make it local to beforeEach().

This reduces the surface area of globals exposed to all tests.

There were two describe('AnnotationController') blocks
containing very similar code.

Remove the tests from the second block which duplicated
those in the first and merge the others.

 * Also remove unused 'momentFilter' dep

Convert filters in the annotation directive to plain functions

The annotation directive used a set of filters for formatting
document domains, titles and usernames.

Converting these to plain functions eliminates a bunch of boilerplate
and as noted at https://www.binpress.com/tutorial/speeding-up-angular-js-with-simple-optimizations/135
is a small performance optimization.

Make annotation directive more consistent with other directives

 * Make it an element directive and use the existing utility
   functions for instantiating them in tests
 * Use '=' bindings for input properties and 'on<EventName>' names
   for events
 * Remove unused 'showReplyCount' input property and the
   shouldShowNumReplies() function which was only used
   as the argument to this property.

Don't crash out if username blacklist doesn't load

Frontend cleanups

Fix reply notification worker

These files were converted from CoffeeScript and 'use strict'
was never added.

This removes the use of compass mixins for transition
properties, where the mixin was used for vendor prefixing,
a problem now solved by autoprefixer.

This enables the sidebar app to function with only
jQLite, rather than the full jQuery library.

The main differences are:

 - jqLite's find() method only supports tag names.
   Element.querySelector() can be used instead
 - jqLite-wrapped input elements do not have a focus()
   method. Just call focus() on the input instead
 - The DOM focus() and select() methods are not fluent
   like their jQuery counterparts

Add developer API tokens

Add a /profile/developer/ page where users can generate and re-generate
their API token. This token can be used as a Bearer token in the
Authorization header in API requests instead of using one of the more
complex and short-lived JWT tokens that the client uses to authenticate
API requests.

The tokens are just randomly generated opaque strings, each one
associated with one user account. There's 0 or 1 token per user, and the
user can regenerate their token at any time. The tokens are stored in a
`token` table in the db that just maps token values to userids.

Notes:

- Our authentication policy now calls the new API token validator first
  for API requests. If this validator does not accept the token, then it
  passes it to the legacy JWT validator (which is still used by our
  client).

  The idea is that if we add more types of API token in the future, the
  authentication policy will have a list of different validator
  functions for different token types, and will try each validator in
  turn until either one of them accepts the token or it runs out of
  validators.

  The use of a type prefix string at the beginning of tokens means that
  validators can usually reject tokens without a db lookup, so we won't
  end up with one db lookup per validator.

- The new tokens always start with u"6879-". If a token sent by a user
  doesn't start with this prefix then the token validator can reject it
  out of hand, without doing a database lookup.

  An opaque number is used for this prefix because we want users to
  treat API tokens as opaque, rather than using a human-readable prefix
  that makes it obvious what type of token you're looking at. (But the type
  of the token is not "secret" in any real sense.)

  In the future it's intended that we'll have different types of tokens
  identified by different prefixes, and different types of token might
  (for example) give access to different capabilities.

- The legacy JWT tokens (still used by our own client) do not have any
  such prefix. If all other token validators (currently just the one new
  API tokens validator) reject a token, then the auth policy will fall
  back to the legacy JWT token validator.

  I think it might be possible that a JWT by random chance could begin
  with u"6879-". If that happens then the new API tokens validator would
  not reject the token based on its prefix and would do a db lookup, but
  the lookup would return nothing and the validator would then reject
  the token, and the auth policy would then move on to the legacy JWT
  validator which would accept the token. So it would be okay.

- There's no foreign key constraint from the token table's userid column
  to the user table, because the user table belongs to the app whereas
  the token table belongs to the api.

Postgres annotations

Fix broken promises in IE

Fixes #2953.

We support IE10/11, neither of which define Promise globals, so make
jshint warn if we use Promise without explicitly defining it (by
importing a polyfill).