Structured exclusion rules internally, and on the popup and options pages

Follow up to #1143 (and the aborted #1150).

This implements structured exclusion rules internally, and on the popup and options pages.

Comments and issues:

- There's no change in functionality here (over #1143).  Just changes to the internal representation and the popup and options pages.

- Check out the browser-action popup.  It's pre-populated and updates its state depending upon what's currently in the input fields.  It's not quite possible... but I did consider whether the popup is now sufficiently functional that we could remove exclusions from the options page completely.

- On the options page, exclusion rules are now structured elements (as opposed to flat text).  Since order matters, it would be nice to have `Move Up` and `Move Down` buttons.  However, to my eye, it's pretty cramped already, so I left this out.  There is no `Add Rule` button.  A new (empty) row appears when you hit `Save Options`.

- I originally implemented caching for `Exclusions.getRule()`.  But it turns out that the hit rate is low (about 20%, for me).  Which means that the cache would become too large too quickly, and be of little benefit anyway.  So I removed that and implemented a `RegExp` cache instead.  We still do a linear scan on each change of tab, but it is no longer necessary to parse JSON and build RegExps each time (as was previously the case).  

- I didn't want to put lots of exclusion-rule logic in `options.coffee`.  So I added a new type of option, a *self-handling option*.  There are various ways in which this could be done, so perhaps somebody should take a closer look at it.

- The PR includes code for migrating from the old `excludedUrls` setting to the new `exclusionRules` setting.

- The PR plays nicely with the syncing of settings across multiple chrome instances.

- There's an awful lot of code: sorry about that.

- Comments from @philc in #1143 and @deiga in #1150 have been taken into account: Thanks!

As ever, comments are welcome.

Please try it out.  There's quite come change to the user interface for configuring exclusion rules.

I think a good mental model for the code organization here is the Settings page handles the UI for viewing and editing settings (so any UI generation code should be as close to the Settings page JS as possible). For the data model, every field has a set of functions for
1. getting its value
2. saving it
3. running needed business logic when it gets changed
4. restoring from the default
5. (perhaps) generate the HTML for a field

You could bundle those 4 functions into a unit, or enumerate them separately, I don't have a strong opinion.

When a field doesn't have a special handler, it uses the default handlers, which is what the options page is today.

Your new complex field needing its own persistence logic then fits into this framework nicely, and feels less like a special case.

The way this logic is currently named and documented makes it seem like there's a lot more machinery than there is. I haven't looked carefully at the final code (only the diff) enough to say that this is the right simplification, but it's food for thought in case it resonates as a simplication.