Add a test for the controller part of the <groups-list> directive.

We have a couple of different patterns for testing directive
controllers in the code, the approach taken here follows the privacy
dropdown's directive in simply exporting the controller's constructor
as a 'private' export and referencing it directly in the test.

 * Rename the exports in the 'directive/privacy' module for consistency

 * Restructure the 'New group' item to make icon
   and label align with the items above it

 * Make the whole 'New group' section clickable

 * Make 'New group' icon bold for visual consistency
   with other icons

 * Use the prerendered group URL from the API instead
   of generating it locally

Card 87

 * Use an element directive for <group-list> for
   consistency with the <privacy> directive and because
   the directive has its own template.

 * Use flexbox for easier layout of items in the groups
   dropdown list.

 * Update the hover and selection states of items in the dropdown
   list as per the mocks.

 * Add descriptive titles to all links in the list

Card 87

 * Use the brand color for hovered items,
   including selected items.

Card 87

Use nesting for readability.

Card 87

Use a light grey background.

Card 87

Add make target to run karma tests with auto-watch enabled

Show orphan annotations with a notice

The positions of the anchors are no longer needed.

This provides a convenient way to start Karma tests and auto-run
them when test files are changed.

Because the test files are incorporated into a Browserify bundle
by karma-browserify which watches files for changes via watchify(),
we can turn off Karma's own watching of the test files.

This fixes a problem where changing a test spec file would result
in Karma running all the tests twice, once after the test spec file
changed and then again afterwards due to the browserify bundle
being updated a second or two after the test spec file changes.

DRY in .editorconfig and add SCSS settings

cf410d0 broke thread sorting by interfering with the (admittedly
arcane) sort apparatus.

There is a scope.watch in the AppController which is responsible for
filling the `predicate` field of the `sort` object when the `name` field
changes. In order for this to work, the controllers in child scopes
(namely StreamController or WidgetController) need to modify the `name`
property of the `sort` object in the parent scope, via prototypal
inheritance, rather than replacing the entire `sort` object.

Clean up socket, threading, mapper with routing

Move all the logic required to set up a clean environment for the
client views into the dependency resolution mechanism of ngRoute.

The annotation mapper gains an unloadAnnotations method to make the
isolated code cleaner.

Use angular-websocket to remove the need for our own socket class.

The AppController becomes much more sane.

Merge pull request #2475 from hypothesis/oWe60V8v-signal-when-there-are-public-annotations-on-a-page

Signal when there are public annotations on a page in the Chrome extension icon

I was getting multiple test fails on Travis that were not failing
locally, due to differences between my local Sinon and Travis's. Pinning
Sinon to the latest version fixes this.

Add a simple user info dashboard for admins

Allows administrators to look up user information from the
administration panel.

Close #1916

Installation docs corrections

Split host / sidebar and clean up plugin loading

Improve factoring of search/filtering

Refactor Pyramid routing and view configuration

Lenient search

More variable substitution becomes available.

Keep weaning off jQuery.

Fix issues with Object.getOwnPropertyNames under PhantomJS.

Let each frame just emit the event locally and invoke its own local
method in response to the RPC call. The widget, acting as the hub
of the communication bridge, stops infinite RPC loop by only
propagating the call when it would change the state.

Publish to a group

Features
========

1. If you have a group selected in the groups dropdown when you create
   an annotation, the annotation will be created in that group.

2. Only users who are members of the group can see the group's
   annotations.

3. An annotation can be separately set to public or private, whether it
   is in a group or not, using the separate visibility dropdown on the
   annotation card when creating or editing an annotation.

   Private means viewable by the user only, public means viewable by the
   group or by everyone if the annotation has no group. When in a group
   the group's name appears instead of "Public" in the user interface
   (and with a group icon instead of the public icon). So for example if
   I make an annotation in group Foobar I can set its visibility to Only
   Me or to Foobar.

4. New icons and styles for all the group-related parts of the UI,
   should look the same as in Jake's mockups now.

Implementation Notes
====================

Auth
----

- We add `"group:<hashid>"` principals to `request.effective_principals`
  for each group the user is a member of.

- The existing `"group:admin"` and `"group:staff"` principals are
  renamed to `"group:__admin__"` and `"group:__staff__"` so that they
  never clash with group hashids (hashids never contain _'s).

- A user may only create an annotation in group "x" if they are
  themselves a member of group "x". This is enforced by an ACL
  in `h.api.resources`.

- Users may only view annotations in groups of which they are members.
  This is enforced by a query filter in search: `h.api.groups.search`.

- In `h.api.groups.logic`: A reply's group is always set to that of its
  parent, server-side. It doesn't matter what the client sends.

Search Filtering
----------------

- Whether an annotation belongs to a group is recorded in a top-level
  `group` field in the annotation. The value of this field is the
  group's hashid.

  For example, it is currently possible to have a private annotation
  (visible only to the user who created it) within a group. This allows
  users to use the privacy controls for "drafting" group annotations and
  replies, only sharing them with the group when they're ready. It also
  allows users to keep private replies to group annotations.

  When the sidebar is focused on a group (not yet implemented), the
  search will filter the annotations to those that have the group's
  hashid in the group field, regardless of whether the annotation's
  permissions are private to the user or shared with the group.

- The groups search filtering (`h.api.groups.search`) uses the top-level
  groups field to filter out annotations that belong to groups that the
  user isn't a member of.

- Annotations that are public simply have a group field containing
  `__world__`.

Client-Side
-----------

- `annotation.coffee` sets the group field on the annotation before
  saving it.

- There's a new group-list-controller to handle the now more interactive
  groups dropdown.

- And a group-service to share state about which group is currently
  focused with different parts of the code.

Misc
----

- `h.streamer`: Infinite scroll and live updates filter out annotations
  from groups the user isn't a member of, as well.

- `h.api.search.transform`: the API adds group: '__world__' to any
  annotations without a group field before returning them to the
  client.

Add clickToClose option

Don't show CC0 license on Only Me annotations