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.

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.

Correct the title of the documentation

Flesh out the docs for building the docs

URL queries should now use uri encoded strings for all default filter queries.

Fix client failing to load on pages that define `self`

Make these more user friendly and helpful, less knowledge assumed, but
still very terse.

Update README

Add embedding label

This is so the h docs can cross-ref to this page using intersphinx.

Now that this git repo has Sphinx docs published at
http://h.readthedocs.io/projects/client/, the README should link to
those.

I also reworded a bit to make it more similar to the intro in the Sphinx
docs.

Reorganise docs

Change the docs directory (which was just a directory of markdown files)
to a reStructuredText / Sphinx project.

Docs are reorganized by audience.

Some docs (for example embedding.rst) are copied over from the h repo's
docs. These will be removed from the h repo after this commit is merged.

This project enables the user to include a default filter query as part of a url.

The syntax works with the #annotations: fragment.  If a Q: or Query: (case insensitive)
is included, whatever follows the query will be included in a search filter as a
default.

user tags may be included in this query string. For instance user:USERNAME will
filter for the user called USERNAME. Using an @hypothes.is will search for exactly
that user. So far, the user, tag or any tags are the main permissible items.

So http://www.example.com/path/to/file#annotations:Q:user:USERNAMEtag:TAGany:KEYWORD

will filter the page for annotations by USERNAME tagged TAG and containing KEYWORD.

These are documentation files intended for publishers who're embedding h
in their sites, they're being removed from the h repo into this client
repo.

There may be some reStructuredText syntax in these files that doesn't
work on GitHub (only in Sphinx or only on readthedocs) but these client
docs are about to be moved over to Sphinx/readthedocs anyway.

Keep all the docs for publishers (i.e. people who run websites that
publish content, and want to embed the h client into their site)
together in one docs/publishers folder.

Edit assetRoot and sidebarAppUrl docs

Fix client failing to load on pages that define `self` to be something
other than `window`.

When AnnotatorJS is bundled by browserify, it is first processed by
browserify-shim* which adds references to a variable called 'global',
which exists in Node but not the browser. Browserify then processes the
result and assigns `global` to the value of the first variable from
['global', 'self', 'window'] which is already defined.

https://github.com/hypothesis/h/pull/3385 fixed the problem when the
page defines a variable called 'global' that is not an alias for
'window' by reducing this list to ['self', 'window']. This still leaves
pages that define 'self'.

This commit fixes the problem by always making `global` (within CommonJS
modules) always be assigned the value of `window`.

* browserify-shim deals with the fact that AnnotatorJS 1.2.x is not a
CommonJS module and exports its entry point as `window.Annotator`.

- Clarify that if any service is specified it's used _instead of_, not
in addition to, the default hypothes.is service

- Add note that services settings are still experimental

- Edit the text for clarity

I still don't think the `authority` setting is very well described here,
but I think that setting may be going away in the future, so I'm not
going to try and document it better right now.

The `grantToken` setting could still do with much better docs as well.

Move the docs for these two config settings into their own section in
the docs, and note that they're experimental.

Rename the onLogin callback to onLoginRequest

Remove sourcemap link from boot script

The previous regex would have matched any line that happened to contain
the text 'sourceMappingURL'.

The trigger for invoking this callback function is the user requesting
that a login flow be started. In other words, at the point this callback
is invoked, a login has not occurred, and indeed may never occur if the
user does not complete the login flow.

As such, it seems clearer to have this callback called "onLoginRequest"
rather than "onLogin."

Fixes #274.

Add docs for on login

"Keys" here is programmer jargon, and hopefully the client configuration
documented on this page should be usable by people who aren't
programmers.