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.

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

The js-polyfills library is a nice one. It provides enough for
PhantomJS and it provides the URL polyfill. However, we keep core-js
since for production it's better to have the lightweight requirement
of just the es6.promise module without global namespace pollution.

We tolerate pollution of the global namespace for browsers with a
broken or absent URL constructor implementation.

Annotating under IE10 works now!

With this change, there is no longer any patching of the global
object from node-iterator-shim. I believe that's the end of all the
global patching in all of our code. Only Annotator and jQuery remain
in the global space, but both are removed with noConflict.

Nice and clean.

The scroll-into-view module already depends on raf, it's tiny, and
this lets us drop the bundled vendor lib. It also makes the guest
and host tests more consistent.

This lets us require Promise without polluting the global namespace.
Additionally, the core-js implementation has immediacy hacks that
will make it more performant for IE.

This also caught some issues with our async tests.

And hey, it's about 700 bytes smaller, too!

This fixes the dialogs to have the same space around them as the
main content. It's a bit like re-introducing the #wrapper, but with
a class this time that's re-used by the topbar for sizing its content.

This is a little bit confusing, but it is better this way. It's
confusing because webassets doesn't set the compass image directory,
so the paths still have an "images/" prefix. However, the cssrewrite
filter uses the output URL from webassets and that will be an absolute
URL at request time. The compass filter uses only the base URL from the
environment configuration, which is relative. Letting compass do the
rewriting therefore results in merged compass files having correct, but
relative, paths regardless of whether the assets are generated at the
command line or at request time. This should make it possible to pre-
compile the assets before the first request without generating bad
URLs, and to virtual host the application under multiple URLs.

In order to upgrade clean-css it is necessary to import the filter
definition from the future version of webassets. This version takes
extra arguments in the filter configuration, allowing us to disable
the advanced optimizations that became the default in 3.0+ but that
breaks some of our styles.