Rename all the tests to better reflect what they actually test.

Mostly replacing broadcast local event bus publisher proxying with
"calls function", plus a couple of other clarifications.

Before:

  AnnotationSync
    channel event handlers
      the "deleteAnnotation" event
        ✓ broadcasts the "annotationDeleted" event over the local event bus
        ✓ calls back with a formatted annotation
        ✓ removes an existing entry from the cache before the event is triggered
        ✓ removes the annotation from the cache
      the "loadAnnotations" event
        ✓ publishes the "annotationsLoaded" event
    event handlers
      the "beforeAnnotationCreated" event
        ✓ proxies the event over the bridge
        ✓ returns early if the annotation has a tag

After:

  AnnotationSync
    #constructor
      when "deleteAnnotation" is published
        ✓ calls emit("annotationDeleted")
        ✓ calls the 'deleteAnnotation' event's callback function
        ✓ deletes any existing annotation from its cache before calling emit
        ✓ deletes any existing annotation from its cache
      when "loadAnnotations" is published
        ✓ calls emit("annotationsLoaded")
      when "beforeAnnotationCreated" is emitted
        ✓ calls bridge.call() passing the event
        if the annotation has a $tag
          ✓ does not call bridge.call()

If the tests are grouped according to what class / method / function
they're testing, then it's a lot easier to see what is being tested and
what isn't, and it's easier to find the tests for `foo()` or to know where
to put new tests for `foo()`.

On the other hand when you names tests like
`describe('channel event handlers',` `describe('event handlers',`
`describe('the "loadAnnotations" event',`,
`describe('the "deleteAnnotation" event',` etc then it can be a lot
harder for a reader coming along later to understand how the tests are
organized and how this organization relates to the code itself.

Most of the examples on https://mochajs.org/ use this style of
organizing tests:

    describe('Array', function() {
      describe('#indexOf()', function() {
        it(...
        ...
      });

      describe('#concat()', function () {
        it(...
        ...
      });

      describe('#slice()', function () {
        it(...
        ...
      });

    describe('User', function() {
      describe('#save()', function() {
        it(...

    describe('Connection', function() {
      describe('#find()', function() {
        it(...

This commit reorganizes the AnnotationSync tests along the same lines.

I've also made use of Mocha's `context()` function to group tests
**within a `describe()` for a method** by context. `context()` is just
an alias for `describe()`, but it has different semantics. (This is
also in line with how `context()` is used in the mochajs.org examples).

Translate AnnotationSync tests to JavaScript

Tidy the CoffeeScript-generated annotation-sync-test.js into something
more human readable.

Convert `<group-list>` to a component

Just the minimal changes necessary to stop `make lint` from complaining,
while still having `make test` pass.

Some code can be deleted because (eslint informs us) it was unused.

`annotation-sync-test.js` is the unmodified output of
`coffee -bc src/annotator/test/annotation-sync-test.coffee`.

Add a branding directive to bring custom branding to sidebar

Fix annotation ID not being passed to moderation banner correctly.

Add missing `vm.` prefix and test. This was missed when testing the PR
because the banner was enabled by modifying the banner's controller
instead of the app state.

* Implement <moderation-banner> component

Implement the UI component for the moderation banner at the top of
annotation cards, following the designs on [1].

[1] https://github.com/hypothesis/product-backlog/issues/183

* Add reducer and actions for managing moderation app state

Add a module which defines the state and actions related to moderation
status of annotations.

* Display moderation banner at the top of annotation cards

The moderation banner is currently only supported on top-level
annotations. It will need to be adjusted and moved to a different
component in order to support replies.

* Support displaying moderation banner above replies.

 * Move the `<moderation-banner>` component to `<annotation-thread>` so
   that it can be displayed for replies as well as annotations.

 * Customize the styling of the banner when the annotation is a reply.

* Add a simple test for display change when moderation banner is used on a reply

* Add additional parameter documentation

* Convert `<moderation-banner>` to a component

As per hypothesis/client#292, all element directives are being converted
to components.

* Add tooltips to moderation banner buttons.

The "Hide" and "Undo" labels for the button were potentially ambiguous.
The final labels are still being discussed but improve the UI by adding
tooltips and changing "Undo" to "Unhide".

* Correct a reference to a button label in tests

The label changed from "Undo" to "Unhide".

https://github.com/hypothesis/product-backlog/issues/181

Just export the component definition rather than an object containing
both the controller and the component definition as a property.

Say "h" not "the Hypothesis web service"

Move ng components from src/sidebar/directive to src/sidebar/components

Docs adrs tweaks

This makes the dir name match the type of object these modules export.

Convert element directives to components

Add ADR for adopting a component-based architecture for the UI

Query from url

 * Separate the 'Context' section into relevant background information
   and client-specific context.

 * Explicitly state in the 'Decision' section that `angular.component()`
   will be used.

The docs for h now refer to it as just "h" and not "the Hypothesis web
service":

https://github.com/hypothesis/h/pull/4434
https://github.com/hypothesis/h/pull/4435

Update this repo's docs to just say "h" not "Hypothesis web service"
when referring to the web app as opposed to the specific instance of the
web app hosted at hypothes.is.

This ADR provides an explicit write-up of how the UI is structured and
describes some changes we can make to the client to make this structure
more obvious and eliminate inconsistencies.

Components should use `bindings` rather than `scope` to declare inputs
and outputs.

Several directives should be registered as components but will require
refactoring before this is possible.