Add completion for qutebrowser

Adds a command to qutebrowser to add/edit rules in the scope of the domain of the current tab. Adds a completion for that command. Also a command to write out the ruleset to the config file. The Rule -> str converter for that will have to be maintained along with the one that goes the other way when that is expanded.

I don't think I am using the completion model properly. I am just making it all one column with all the details I need to take the action in it. The alternative would be to have the first column as an index and save the completionmodel somewhere we could refer to it. I think.

SEEN_REQUESTS will grow for ever. It would be nice to have it tab scoped like a bit of ... tab data! Maybe an idea for the plugin API once tabs and windows into it.

Now importing completion stuff from qutebrowser.completion.models and objreg (dammit) from qutebrowser.utils, that last one will probably go away once we add tabs to the plugin api.

The completion initially shows the requests that have been made and the action applied but once you toggle a row (and reopen the completion) that line will show the future state of such requests. So it is kind of a mixed message but is better than the alternative (after you blocked something it would still look like it was allowed if that request hadn't been made again in the interim). It also doesn't update the model when new requests are made while it is open.

It would be nice to define a completion mode command to do the thing so you didn't have to re-open the completion after every action if you wanted to do a bunch of them. But that would probably need to be added to qutebrowser and provided as an opt-in via an arg to cmdutils.argument.

map_to_rules isn't in the same format as the other way around (different handlers per flag). I didn't want to duplicate all that that stuff and, uh, YAGNI?

I didn't like how the flags lose specificity as compared to the text file. Instead of putting them in a set and having the flag name imply the state why not just have it in a dict with flags as keys and a bool as value?

There isn't much point putting unsupported rules in the default context if it is just going to complain about it on stdout every time you start. Also with the new write out command they will get lost anyway because they aren't being stored in the config.