The embed code has for some time been the place where our application
is bootstrapped. When we did the epub.js integration, we added query
parameters to the embed.js view to control which plugins were loaded
by each instance of the application (a widget host for the reader frame
and a slimmer guest annotator for the chapter frames).

Change the injection bundle to instead include a separate bootstrap
script. This has the nice benefit of ensuring that while we still use
yepnope or a similar technique for script injection that our bootstrap
code runs in the same global context as the application dependencies
whether or not the embed script is run in a normal context or a Chrome
extension content script context. The need for an inline script created
by the embed code is no longer, since it is a separate script fetched
from the server (it's bundled in production, inside the monolithic
hypothesis-assets.js).

Instead of passing the URI of the sidebar iframe by templating the
bootstrap script, the embed script adds a link tag to the page with
``rel=sidebar`` and ``type=application/annotator+html``, which the
bootstrap script looks for. This pattern fits nicely with the existing
role of ``rel=sidebar`` in Firefox and Opera and nicely decouples the
embeding and the bootstrapping.

Further customization that used to take place in the query parameters
is now done through ``window.hypothesisRole``, which can specify an
alternate constructor, and ``window.hypothesisConfig``, which can be
a function to configure the options passed to the constructor. This
function will be useful for Single Sign On options, too, as laid out
in #1437.

The destroy script from the Chrome extension is put alongside the new
bootstrap script, as they complement one another and are not extension
specific.