Passkeys: Pass some keys to the underlying web page without wholly disabling Vimium.

See #491.  Here you go, @philc, as promised.

Approach.  Extend the meaning of the `Excluded URLs` option as follows...

````
http*://mail.google.com/*
````
means Vimium is wholly disabled on Gmail (as before).

````
http*://mail.google.com/* jknpc
````
means that *only these five keys* (`jknpc`) are excluded.  They are passed through to Gmail, and the Gmail bindings are used.  Vimium handles all other keys.

Something like this works too (the extra spaces are ignored):
````
http*://mail.google.com/* jk np c
````

Other changes:

- If there is an existing exclusion (with or without passkeys), then the popup page for new excluded URLs is now pre-populated with the existing exclusion.

- There's a new icon for pages with pass keys defined (although I'm no graphic designer).

- The way in which state is handled has been substantially rewritten, because there are now more ways in which the state of an existing tab can change.

Issues...

- If `t` is a passKey, then how should `gt` and `99t` be handled?  Here, if there are prefix keys in the queue, then `t` is no longer passed through.  So `gt` and `99t` work as before, but just `t` is passed through.

- The configuration interface on the options page is poor (in fact, it's never been great).  However, I'm not keen on doing too much work on that since the options page really needs a full work over, and that should be done separately.

- Currently, it is only possible to pass through simple keys (so no modifiers, so no `<c-a>`, and the like). Capital letters are ok.  It is not possible to pass through the space key.

- Previously, the order of excluded URLs did not matter.  Now, the order does matter,  The passKeys you get are those associated with the first matching pattern.  This could affect the UX.

- There's a race condition (see `main.coffee`, around line 540).  Part of the key handling is done in the content script, and part in the background page. So it's difficult to get around this.  I think similar race conditions may have existed for years.

- There are currently no unit tests.  I'm not sure how to write useful tests.  The behaviour is so dependent on the way chrome handles keystrokes events and message passing.  I'll think about this and return to it later. *Edit: some very basic unit tests have been added.*

- This PR does not address #491, temporarily disabling Vimium.  Although, it wouldn't be hard to get there from here.

There are probably other issues.  I'll raise them below as I think of them.  And I'm sure others will do the same.

Comments, suggestions welcome.

Why do we need to return true here and in the other handlers? I haven't looked at the entirety of the code recently, but can we avoid adding the listeners altogether if isEnabledForUrl is false?