Convert `<hypothesis-app>` to a component

Rename the modules and templates for the `<hypothesis-app>` component to
match the component name, following our conventions.

Fix scrolling to new annotations

Convert AnnotationViewerController to a component

Output logs from s3-npm-publish Docker container

Since #306 which set the height of the `<hypothesis-app>` container
element to 100%, the height of `document.body` is now equal to the
window's `innerHeight`. As a result, `document.body.clientHeight` now
returns the same value as `window.innerHeight` and `scrollOffset()`
returns 0.

Fix this by using `scrollHeight` instead of `clientHeight`, which takes
into account the height of all of the body's descendant elements,
including the `<thread-list>`.

This calculation would still return the wrong result if the
`<thread-list>` were ever placed in a separate scrolling container
within the sidebar app window, but that is an acceptible limitation for
now.

When this test was converted from CoffeeScript to JS, the implicit
return of the Promise was not converted to an explicit return. Hence the
test would sporadically fail depending on when the Promise callback got
executed.

To help debug publishing failures, output logs from the container.  See
https://hypothes-is.slack.com/archives/C076LQFA4/p1490705667081734

Convert `<markdown>` to a component

Convert AnnotationViewerController to an `<annotation-viewer-content>`
component following the same refactoring that was applied to the sidebar
and stream.

Convert StreamController to a component

Strikethrough & apply greyscale/contrast effects to hidden annotations

Convert the `StreamController` controller which provides the logic for
the content area of the stream into a `<stream-content>` component.

Convert `WidgetController` into a `<sidebar-content>` component

Rename `textClass` input to `customTextClass` as per CR feedback.

Adding auth metrics for login, logout, and signup requested

Adding analytics to share functions

This function is no longer inherited from the parent scope since
`<sidebar-content>` is now a component.

Since this helper function is only used by the sidebar, move it
to the SidebarContentController controller.

Convert 'WidgetController' into a `<sidebar-content>` component which
uses `sidebar_content.html` as a template and convert the route for the
sidebar into a trivial template which just renders this component.

 * Move `widget-controller` to src/sidebar/components/sidebar-content.js

 * Move various helpers for the sidebar content template from the scope
   to the controller, in line with other components.

 * Pass the "auth" and "search" scope properties from the AppController
   instance explicitly to `<sidebar-content>`, since components do not
   inherit scope properties automatically.

Split viewer.html template into one template per app type

Branded sidebar

Convert `<excerpt>` to a component

Reorganize annotation sync tests

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).