Show adder if user makes a selection and then launches the plugin.

Clean up reply notifications code

Make client test page load embed from same hostname as test page

See https://blog.readthedocs.com/securing-subdomains/

Try to avoid showing the adder above the selected text where possible by
showing the adder above or below the selection depending on whether the
selection was made forwards, in which case the focus point is assumed to
be at the bottom of the selection, or backwards, in which case the focus
point is assumed to be at the top of the selection.

If the last line of the selection is very close to the top of the screen
then show the adder pointing up at the text rather than down at it.

Also constrain the adder's position so that it never appears outside the
viewport.

Extract the adder styles and logic into separate files for easier
testing and extension.

Also extract the styling for positioning the arrow out into a a helper
class so we can more easily reposition the arrow depending on the
available space.

If a user selects some text, and then realises that Hypothesis isn't
active, their first reaction will probably be to activate Hypothesis.
In this scenario, we should pop up the adder near the selection on launch.

 * If there is a selection when the 'ready' event fires, show the adder
   at the focus point of the selection.

 * For consistency, show the adder at the focus point of the selection
   after a selection whilst Hypothesis is active.

 * Add 'range-util' module which provides utility functions to get
   the coordinates at the end of the selection.

   'range-util' uses the DOM Range, Selection and NodeIterator APIs directly
   rather than Annotator's Range functions for several reasons:

   1) Given that H now requires IE >= 10, all of our target browsers
      have all the APIs that we need.

   2) Using the DOM APIs directly proved easier to debug and test.

Fix front-end build - pin node-sass dependency to v3.4.x

Fix build by pinning node-sass dependency (used indirectly via
gulp-sass) to v3.4.x until
https://github.com/Igosuki/compass-mixins/pull/86 is resolved.

Previously the live reload server at http://localhost:3000 hardcoded the
embed script to 'http://localhost:5000' which would cause the embed to
fail to load if accessing the live reload server via a different IP.

This happens when accessing the server through a VirtualBox Guest when
using the default networking settings or when accessing it from a say, a
mobile device on the same WiFi network as a laptop serving the dev
environment.

Instead use the same hostname for the live reload WebSocket server
and embed script as the client test page is served from.

Update front-end testing dependencies to current versions and switch to mocha reporter

Fix a couple of slow front-end tests and enable slow test reporting

This should help to catch slow tests in development before they become
flakey failures on Travis.

 * Avoid `assert.includes()` in Bridge test, since this does a deep
   equality comparison which is much more expensive than necessary
   (50-60ms to execute on a desktop system with no contention. I think
   this might explain the very occassional failure seen on Travis).

 * Use the correct name for the `retries` option in a
   retryPromiseOperation() test. This test should have failed but
   because the min timeout value was set so low, the test was taking < 2
   seconds to run even though it was retrying 10 times with an
   expontentially increasing timeout.

When running tests in `gulp watch` mode, the initial run passed but
subsequent changes resulted in an error in the `merge-descriptors`
package, related to PhantomJS.

I haven't looked deeply into the problem but it does look like a
familiar issue related to Proxyquire trying to 'call through' to the
original imports in the module. Adding the '@noCallThru' flag in
guest-test.coffee resolves the issue.

This produces more helpful output when test assertions involving deep
equality checks fail.

See https://www.npmjs.com/package/karma-mocha-reporter#showdiff

This requires karma-mocha >= v0.2.2

Update test and development dependencies to latest versions from npm,
except for PhantomJS. The PhantomJS 1.9.x -> 2.x transition requires
additional changes in tests.

A couple of issues came up during the upgrade:

 - 'constructor' is no longer a valid name for describe() blocks

 - The require() in Karma's Browserify config ended up being resolved
   relative to the location of karma.config.js for reasons I haven't
   debugged, instead of looking in node_modules/. Using
   require.resolve() to get the absolute path works around the issue.

Return all canonical uris when expanding a canonical uri

[Update annotations in Pg 1/3]: Fix reply template for postgres

* Changes to html.

Clear pending timeouts when AppController is destroyed

Fix a flaky AppController test and potential causes of flakyness or
runtime errors in other tests due to timeouts set up in directives or
controllers firing after the associated scope is destroyed.

Add a helper which sets a timeout that is cleared automatically
when an associated scope is destroyed.

In the AppController test this manifested itself with a timeout
being called when `$document[0]` was not set.

Fix Hypothesis on local HTML documents

Markdown rendering refactor and math sanitization fixes

Fix an off-by-one error in PDF anchoring code

KaTeX escapes its own input and we trust it to generate safe HTML as
output. Passing HTML generated by KaTeX through ngSanitize can mangle
the result.  eg. The formatting of the infinity symbol is corrupted when
using this test block for example:

  $$\lim_{x \to \infty} \exp(-x) = 0$$

This commit rewrites the rendering logic to only sanitize the markdown
output from Showdown.

This additionally fixes an issue where text that _happened_ to also
be valid markdown in the rendered math would be rendered as markdown,
which is not what we want.

Create a single instance on the first call and cache it afterwards.

 - Add a test that input markdown is sanitized with ngSanitize

 - Add a test that verifies that malformed HTML is tolerated.

Angular 1.5.x no longer throws an exception when the input HTML is
malformed. This adds a test to catch any potential changes in future and
document the expected behavior.

Fixes #2970
Fixes #2935

Make it easier to verify that rendered content is sanitized correctly by
feeding the final HTML string to $sanitize once, instead of trying to
sanitize pieces individually.

In the process, this fixes a bug with the previous implementation where
inline math was rendered if it started or ended with either '\(' or
'\)'. The new implementation requires that inline math blocks start with
only '\(' and must have a matching '\)'

This logic has now been moved to render-markdown.js

Extract markdown and math rendering out of the editor
component into a separate module and add tests.

The PDF anchoring code systematically failed to anchor annotations made
at the very start of a PDF page, due to an off-by-one error in
determining the page associated with a given text offset.

Fixes #2418.

The only thing stopping Hypothesis from working on local (i.e. file://
URL) HTML documents is the failure of the discovery module due to quirks
in the `postMessage` security policy.

This commit works around that issue so that embedding or injecting
Hypothesis on local HTML documents works as expected.

Fixes #2005.