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.
Because that action should be idempotent. It shouldn't matter if you call remove twice. What is a problem as you've noticed earlier is that it errors at the moment if you call this on an unsupported file. Will also fix that tomorrow. Thanks for the review, keep it coming.