Improve behavior when selecting pre-created annotations

Selecting a pre-created annotation in the page resulted in a
'You do not have permission to see this annotation' being displayed
because the selection mechanism only supports annotations which have a
server-assigned ID.

This commit improves that behavior by ignoring annotations without IDs
when selecting annotations.

It also fixes an issue in AnnotationUISync that prevents Annotation
objects being replaced in the UI state after they are updated on the
server. Previously AnnotationUISync would receive the tags of
annotations that had been selected in the page and would then look up
annotations in a cache maintained by AnnotationSync in order to get
Annotation objects that could be passed to `annotationUI` functions
which needed objects with an ID.

Fixes #3547

This pins the dependencies as defined in package.json to specific
versions so that everyone builds the same bundles.

See https://docs.npmjs.com/cli/shrinkwrap for details.

This serves two purposes:

- The default `npm install && npm test` now suffices to run the test
  suite. This is what Travis and many other systems will do by default
  to build JavaScript projects.

- It removes the need to do $(shell npm bin) hackery in the Makefile.

We ship only built assets at the moment, with all dependencies directly
bundled, so all dependencies are now "development" dependencies -- i.e.
not required by those installing the `hypothesis` package.

Simplified != FreeBSD, if we're being picky about it:

  https://spdx.org/licenses/

Fix #2965 (3/N) - Match annotations by ID or tag in drafts service and when removing annotations

Currently annotations, page notes, and orphans are all jumbled up in one view.
We want to separate out these three objects from each other so that the user
can better understand what each is, as well as their relationship to the document.

Hide tabs for direct links and when search results are displayed.

https://trello.com/c/OLdLTlLT/342-separate-annotations-and-notes

Hide tabs behind feature flag.

After creating an annotation, we remove the pre-created annotation from
the Redux store and replace it with the saved version from the server.

In order to determine which pre-created annotation to remove when adding
the version from the server, we need to match on local tag, since the
version from the server has no ID - but it does have a local tag since
that is copied across from the pre-to-post created version.

Set a maximum width on the annotation content to prevent it overflowing
the card and set `overflow-wrap` on annotation quotes and bodies so that
long words without any natural breakpoints are broken in the middle if
necessary to prevent overflow.

Fixes #3421

Remove an alternative annotation deletion button which was part of an
older UI for annotation cards and is no longer used.

This fixes an issue where onEditText() would be called unnecessarily
when the markdown editor lost focus.

Simplify the code by just listening for the 'input' event, which all our
target browsers support.

Merge pull request #3529 from hypothesis/3167-do-not-show-you-do-not-have-permission-card-while-waiting-for-document-to-load

Don't show permissions error before annotation

In preparation for making Annotation objects immutable, enable the
drafts service to match local annotations which do not have an ID by
their local tag.

Don't momentarily show a "You do not have permission to see this
annotation" card before showing the annotation when loading a
direct-linked annotation.

Fixes #3167.

When following direct links to annotations on certain documents,
for example large PDF files that take a while to load,
a "You do not have permission to see this annotation" card was being
displayed briefly in place of the annotation card, before quickly being
replaced by the correct annotation card.

Previously the logic of the WidgetController.isLoading() function was to
return true if we are currently waiting for the response to an
annotation search request that we've sent.

The theory is that this was happening:

1. Client loads, but PDF has not yet loaded, so URL is unknown.

2. Since the URL is unknown, the sidebar does not start fetching
   annotations and isLoading() returns false.

3. Since the client a) Has a selection but b) Is not in a loading state
   - it thinks that it failed to fetch the annotation and displays the
   "You do not have permission to see this annotation" message,

4. Once the PDF finishes loading, the URL is updated and that is
   reported to the sidebar which then performs a search query and
   isLoading() starts to return true until the search query response
   arrives then it returns false again.

The fix is to make isLoading() return true if _either_ we've sent an
annotation search request and are waiting on the response _or_ we're
still waiting for the document to finish loading and haven't sent the
search request yet. So instead of returning false, then true, then false
again isLoading() will just keep returning true until both the document
has loaded and the search response has been received, then it will start
returning false.

Tailor API response to client

This function failed to account for the case where the node was
contained by, but not equal to, the range's startContainer.

In new browsers we could just use `Range.isPointInRange()`. Since that
is not available in IE 10/11, add an implementation adapted from
Blink's `Range::isPointInRange()` C++ impl, minus support for the
`offset` parameter.

This fixes an issue where the adder could fail to show up when making
certain selections because `getTextBoundingBoxes()` could incorrectly
fail to find the text nodes within certan ranges.

Fixes #3521

The `annotation.uri` now always is a linkable URI if we got that data
when the annotation got created. There is no need anymore to try and
find another linkable URI from the document data.
This also removes the type check of `annotation.document.title` since
the presentation layer on the backend always returns an array of
strings (or the `title` property is missing).

Fix adder breaking after making a selection containing no text

Use request-scoped rather than thread-local session

Fix missing PDF highlights

fda63b4 unfortunately broke highlighting in PDFs, because the PDF
anchoring code first finds the text in the document, and then uses a
TextPositionSelector and the HTML anchoring code to select a range in
the rendered page for highlighting.

This commit fixes that issue by moving the TextQuoteSelector check up a
level into `Guest#anchor`.

I've added two tests for this in `guest-test.coffee` -- one tests that
annotations where the target contains no TextQuoteSelector are marked as
orphans, and the second tests that the low-level anchoring code is never
called in this case.

I have also removed the integration test, on the basis that I don't
think integration testing failure cases is a good habit to get into.

Fixes #3530.

Update PDF fingerprint searching / handling

Which will then be used as the `target.source` when creating an
annotation.

This will allow us to switch back to using the URL for the
`target.source` when creating annotations, which will then allow us to
link back to the exact document where the annotation was created.

Ignore the selection change if the new selection does not contain
any text.

 - Add missing check for rangeUtil.selectionFocusRect() returning null,
   which happens if the selection contains no text

 - Add tests for selection change handling

 - Create the `Guest` instance with dependencies stubbed out afresh
   for each test case in guest-test.js

Fixes #3523

Follow JSDoc conventions to refer to instance and static members of
objects in tests by using `describe('#instanceMethod')` for method
tests.

Move test factories into tests/common/

Fix unhelpful username error message when registering a new account

Allow multiple 'uri' parameters to the search query

Clean up the welcome page