Refactor Chrome Extension

This PR takes #1665 and build upon it to add:

* A more modular approach to working with the Chrome extension, there are now several components that can be instantiated individually (and tested) without running background.js.
* Unit tests with their own karma config.
* The beginnings of some documentation.
* An "errored" state (no proper handling of this yet though).

There are now four separate components, the `HypothesisChromeExtension` which sets up all the components and binds the event listeners. A `TabStore` which deals with persisting the tab state to local storage. A `TabState` which keeps track of all the tabs and which are active/inactive. A `BrowserAction` which just ensures that the button is displayed correctly and finally a `SidebarInjector` which deals with actually injecting the sidebar into various environments (it's lifted from background.js and is still a mess but at least it's tested now).

All of these have their dependencies passed in which makes them very easy to test and should make it relatively simple to port this over to the FF extension. I've tried to keep away from using Chrome apis where I can. This should also make it more straight forward to move to using content scripts.

Still to do:

- [x] Restore the error states.
- [x] Documentation.
- [x] Fix some inject and remove errors on non html pages.
* ~~Possibly remove the `TabStore` all together, the localStorage API has the nice benefit of supporting `[]` accessors, so if we migrate away from using a serialised JSON object to just namespaced keys we can simplify this object dramatically.~~ - Will do this in a later PR.

I've kind of blitzed through this today after getting fed up with the current background.js so there's likely lots to improve but I'd appreciate feedback. I'm going to continue working on this tomorrow and hopefully we can get at least one of these PR's merged.

The tests are also extreme unit tests, where every dependency is mocked out. I'm still not sure I'm a fan of these kinds of tests but it was the simplest thing to get up and running.

**Feedback**

- [x] The wording of the messages on the error pages is not consistent with the pop-up messages shown when running in bookmarklet mode. We should harmonize those.
- [x] On remote HTML documents, reloading the tab with an active H session results in a double loading situation. All the console messages are doubled; and annotations are loaded twice.
- [x] Error in response to tabs.create: `ReferenceError: state is not defined`
- [x] Error page for `chrome://` protocols.
- [x] BrowserAction icon flashes when reloading a tab.
This code seems overly defensive to me, and as a result is a bit hard to read. Would ``!!result[0]`` work? Or does the result array get truncated if the result is undefined? If so, even ``result && !!result[0]``