Only import known config params from the host page

Add analytics tracking

The previous method of importing config params allowed the host page to
override any configuration parameter provided by the service hosting the
client's app.html file, potentially introducing vulnerabilities.

This PR limits the client to importing only config parameters from a
whitelist. This also has the benefit of clearly documenting all the
parameters that can come from the host page in one place in the code.

Add Google Analytics if settings supply it

Fixes https://github.com/hypothesis/product-backlog/issues/128

Separate sidebar and annotation layer

Update shrinkwrap

Remove one layer of dir traversal after moving karma.config.js from
src/scripts to src/sidebar.

All of the templates are part of the sidebar application.

Separate out the code for:

 - The sidebar application (now in src/sidebar)
 - The annotation layer and client bootstrap (now in src/annotator)
 - Code shared between the two (now in src/shared)

Update the shrinkwrap based on the result of:

 1. Removing `node_modules`

 2. Re-installing dependencies with `npm install` using the
    latest npm v3 release (v3.10.10).

 3. Running `npm shrinkwrap --dev`

The changes are a "dev" key added to all dependencies to signify that
they came from "devDependencies" and some additional babel dependencies
that were missed in a previous shrinkwrap update.

Simplify client source directory structure

The previous location was a vestigate of when the client was part of the
Hypothesis web service.

The 'h/static' directory names are a vestigate from when the client was
part of the Hypothesis web service.

Update to latest version of dom-anchor-text-{quote, position} libs

Adapt to `toRange` returning null in 4.x rather than throwing an
exception if the quote is not found and add a test case for quote
anchoring failing.

See https://github.com/tilgovi/dom-anchor-text-quote/issues/10

This incorporates a fix for a bug in the new `fromRange()` function in
IE/Edge which appeared in the 3.x series. See
https://github.com/tilgovi/dom-anchor-text-position/issues/4

This fixes several issues where creating a selector from a Range object
could fail.

 * Update types.coffee to use the modified interfaces of the libraries
   which now export fromSelector() and toRange() functions rather than
   classes.

 * Update test expectations for the HTML anchoring tests as the updated
   dom-anchor-text-position library fixes a bug that caused most of the
   failures

Remove initial redirect when sidebar loads

Avoid redirecting to '/viewer' when the sidebar loads.

This redirect is unnecessary since the sidebar never changes its mode
once loaded and it caused the viewer embedded on a page to fail to load
when restoring a closed tab in Chrome.

This may also resolve issues where the user agent disallows the
'replaceState' call in certain situations (search prod-client reports on
Sentry for "replaceState")

Fixes #178

Update tag service urls

Show annotations in Annotations tab but with quote struck through after anchoring timeout

Since we're not linking to the stream anymore.

Instead of marking annotations as orphans after the anchoring timeout
expires, instead display them in the Annotations tab but with a visual
indicator that they have not yet anchored. This avoids showing
annotations that are still anchoring in the Orphans tab, which can be
confusing when it happens in long PDF documents with many annotations.

 * Add an `$anchorTimeout` flag to annotations that is set if
   annotations fail to anchor within the timeout period.

 * Display annotations with this flag set in the Annotations tab,
   on the optimistic basis that they will eventually anchor.

 * When rendering annotations with this flag set, display them with
   a quote struck through (same as orphans) to indicate that they are
   pending. The visual representation of the pending state may be
   tweaked in future.

Consolidate logic for annotation <-> tab assignment

Move the list of connected frames to the Redux store

Use a custom element name for highlight spans

Previously the logic for determining which tab an annotation should appear
in occurred both in `root-thread.js` where it was used to filter
annotations based on the selected tab, and in `widget-controller.js` where
it was used to switch to the tab containing a particular annotation.

Consolidate all the logic for deciding which tab an annotation should
appear in into a single module. This makes it easier to test that tab
assignment is correct with different combinations of feature flags and
annotation states and to add additional logic in future.