The adder toolbar uses Shadow DOM or `!important` to prevent CSS rules
in the host page from directly affecting the styling of the toolbar.

However even inside Shadow DOM elements can still inherit CSS property
values from parent elements [1].

This commit fixes that problem for current browsers (except Edge [2]) by
using `all: initial` on the Adder's root element.

[1] See https://github.com/w3c/webcomponents/issues/314
[2] http://caniuse.com/#feat=css-all

Fixes #382

Add config option to show highlights only when sidebar is open

Update jQuery to current version & slim build

Allow publishers to customize log out, profile and help links

Convert the "showHighlights" option from a boolean into an enum with
three values: "always", "never" and "whenSidebarOpen". When the last
mode is selected, highlights will only be shown when the sidebar is
open.

Stubbing `getComputedStyle` in the pointer events test resulted in the
test failing after the jQuery update in the previous commit because the
`css(..)` jQ method used by that test depends on `getComputedStyle`
internally.

Use `serviceConfig()` everywhere

Update our horrifically old jQuery build which included workarounds for
browsers we no longer support to the current stable version of jQuery.

Also switch to using the slim build which excludes features we don't
use.

This reduces the size of the minified jQuery bundle from 96KB to 68KB.

Always use `serviceConfig()` instead of accessing `settings.services`
directly.

If the user is logged in to a third-party account and the host page has
provided an `onHelpRequest` callback function, then call this function
when the _Help_ button in the sidebar's login menu is clicked, instead
of doing the button's normal behavior.

Enable partner sites to customize the behavior of the user profile link
in the sidebar's login menu.

The current behavior of this link is:

* If the user is logged out it doesn't show
* If the user is logged in to a first-party account it does show, and
  links to their https://hypothes.is/users/<username> page
* If the user is logged in to a third-party account then it does show,
  and displays their username, but it is just an unclickable `<span>`
  not a link

This commit changes it so that if the user is logged in to a third-party
account and the host page has provided an `onProfileRequest` callback
function, then the profile link will be clickable and clicking it will
call this callback function instead of linking to a hypothes.is user
page.

If the user is logged in to a third-party account but no
`onProfileRequest` function has been provided, then the link will be
shown unclickable as before.

The current behavior of the log out button in the sidebar is:

* If the user is logged out it doesn't show
* If the user is logged in to a first-party account it does show
* If the user is logged in to a third-party account it **does not** show

Change the log out button to show when the user is logged in to a
third-party account **and the host page has provided an onLogoutRequest
callback function**. When clicked the log out button will call this
callback function, instead of doing the normal (first-party) log out
procedure.

If the user is logged in to a third-party account and no
`onLogoutRequest` callback function has been provided, then the log out
button will not be shown (as before).

When a on*Request callback function is provided by the host page (for
example onLogoutRequest) add a corresponding onLogoutRequestProvided
boolean to the settings object.

This is because the on*Request functions don't get passed from the host
page context into the sidebar code, because functions aren't JSON
stringifiable, so the sidebar code has no way of knowing whether or not
a callback function was provided.

We're going to be adding code to the sidebar that does need to know
this, so add on*RequestProvided settings to tell it.

Reorganize the tests according to the components (the different items in
the login menu) instead of by context.

Instead of:

    when a first party user is logged in
      it shows the profile, account settings, help and log out buttons
    when a third party user is logged in
      it only shows the profile button (but disabled) and the help button username
    etc

We now have:

    describe: the profile button
      when the user is logged out
        it does not show
      when a first party user is logged in
        it shows the enabled profile button
      when a third party user is logged in
        it shows the enabled profile button
      etc

    describe: the log out button
      etc
    etc

This will make the tests easier to write as we're going to be adding
more complex behavior to some of the buttons, both logic about when the
buttons do and don't show and are enabled or disabled, and logic about
what happens when a button is clicked. It'll be easier to manager if all
the tests for each button are grouped together. eorganize tests by
component

There's no need for this function to use `new` or `this`.

Some minor docstring fixes

Show an error message to the user when getting or refreshing an OAuth access token fails

When the client is embedded in a page that includes a services
configuration setting then it logs in to Hypothesis using OAuth,
getting an access token from the Hypothesis API.

The Hypothesis API's OAuth access tokens currently expire after an hour
and must be refreshed by the client before then. When the request to
refresh an access token fails the client continues to look and work
exactly as before from the user's point of view, except that all actions
that require communicating with the API such as creating an annotation
fail and show error messages.

Some actions, such as dismissing the sidebar tutorial, fail with no
error message.

Currently we only try the refresh request once for each access token and
don't retry is the request fails. Even if we did retry the refresh
request can't succeed after the access token has expired - it's always
possible for the client to get into a situation where the access token
is expired and can no longer be refreshed.

The only fix (currently) is for the user to reload the page which will
re-do the initial grant token request to get a new access token.

So when a refresh request fails show an error message to the user
telling them that they need to reload the page.

Show an error if the initial request for an OAuth access token fails.

When the client is embedded in a page that includes a services
configuration setting (see <http://h.readthedocs.io/projects/client/en/latest/publishers/config/#cmdoption-arg-services>)
then it tries to login to Hypothesis using OAuth, exchanging the grant
token from the services config setting for an access token from the
Hypothesis API.

If this request for an access token fails (for example, if the
Hypothesis server responds with an error) then the client ends up in an
invalid state. Some of the sidebar components are not fully rendered,
with visible parts missing, no annotations are shown, and actions such
as trying to create an annotation fail in broken ways.

We should really fix the completely broken appearance and behavior of
the client in this state, but that'll be a big job.

For now, at least show an error message to the user telling them that
they need to reload the page.

There's currently no facility to retry the access token request but if
the user reloads the page the whole process will begin again and the
request will be tried again.

Do not let authors flag their own annotations.

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

parter -> partner

Fix "Login" to "Log in" (consistent with how we spell it in the UI) and
remove an incorrect full stop.

Consistent with how we spell it in the UI.

`yarn publish` is currently an interactive command and therefore not
suitable for use on a CI system. See
https://github.com/yarnpkg/yarn/pull/3391 for details.

Annotator removal cleanup

Cleaning up: moving constructor to be first function in Guest class and removing unused wrapper html field

Remove dependency Annotator.js

Switch package management from npm to yarn