Emit an event on the Guest element, ‘scrollToRange’

Follows DOM event name conventions.

This allows attached handlers to hook into the behaviour of bringing a highlight anchor into view.
The event.detail property contains a native DOM range representing the anchor.
The default scroll behaviour can be prevented with the event.preventDefault method.
The event bubbles upward, meaning a handler could be attached at the guest root element  - right now the document’s body element - and any ancestor.
body -> documentElement -> document -> window

The latest version makes it work for sub-document frames

Merge pull request #481 from hypothesis/dont-show-view-switcher-until-first-batch-of-annotations-received

Don't show view switcher until annotations received

Don't show the view switcher until the first batch of annotations has
been received. (This first batch will be all the annotations, unless
there are more than 200 annotations of the page.)

This is an attempt to reduce "popping" caused by the annotation switcher
suddenly changing a brief time after first render, when annotations are
loaded:

https://github.com/hypothesis/product-backlog/issues/327#issuecomment-312657968

Increase robustness of frame destruction

Find the true URI record for a Document when there’s conflicting info

The previous implementation of this used the iframe’s `src` uri as the key for identifying which frames needed to be removed from the sidebar’s frame-sync state.
We can’t rely on this uri because there could be one or more iframes sharing the same src uri, for example ‘about:blank’ with/without `srcdoc` attribute usage.
Another problem is with a `blob:` uri as the src. Once again the uri in the src can’t be used as the key since it won’t match what frame-sync thinks the proper uri is if it’s being substituted with  `baseURI`.

The way this works now is by tagging the frame info with a random ID called the frameIdentifier. The handling of this tag is coordinated with the relevant modules, cross frame, bridge, frame-sync, etc.

Modified to fit our needs of course..

This happens when an href is set with a URI using the 'blob:' protocol and the document could possibly set a different URI through a <base> tag.
Use the URI from the base URI instead if this is the case.

Fix decoding of the query section in "#annotations" fragments.

Fix view switcher flash on iOS

Use `decodeURIComponent` instead of `decodeURI` because
`decodeURIComponent` decodes reserved characters (eg. ":", "/") whereas
`decodeURI` does not.

Avoid stubbing decodeURIComponent() in the tests and instead just use a
malformed escape sequence which triggers an actual URIError when
decoding.

The view switcher tabs at the top of the sidebar would flash grey for a
moment after you clicked one. This removes the flash.

This webkit "tap highlight" is actually an iOS Safari usability feature,
it indicates to the user that their tap is being successfully recognized, and
indicates which element they're tapping on. But I don't think it looks
good with these tabs of ours, and it seems to interact badly with the
background colour animated transition we're using (it seems to do the
animated transition first and _then_ flash the tap highlight colour for
a second).

We're providing this indication by changing the colour of the tab
anyway, so disable it.

Frame destruction

Set the visibleHighlights state for multiple Guests

Convert Unicode service & tests to JS

Replace selection tabs with view switcher (feature flagged)

If the 'view-switcher' feature flat is enabled then use the new view
switcher component, otherwise uses the old selection tabs component.

The view switcher component is just a placeholder for now.

Also remove use of Angular mock/inject because it really isn't necessary
for testing this service.

Allow "oauthEnabled" setting to be overridden in client config

It makes more sense that this method is implemented in the Sidebar instead of Host

This means that sub-frames will get injected with the same set of whitelisted config values from the top level.
It’s good that there’s a whitelisting of the config before reaching this point, so there’s less of a security concern with the injection

This was done so I can have the sub-frame guests read the `config.showHighlights` option in order to set the initial highlight visibility at that level.

I want to prevent the potential chaining of config params here since I plan to pass the config object around in new places, the sub-frame guest level for example.

This will enable testing of 1st party OAuth in the client by creating a
custom bookmarklet or test page which embeds the client.