There's nothing useful we can display if the destroy action messes up,
so might as well assert it does and complain loudly if it doesn't.

This avoids copy-pasting definitions of set_account.

There are two motivations for this:

1. It looks like we're going to add other features that require
   server-side storage (e.g. user notes).

2. Namespacing glitchsoc modifications is a good idea anyway: even if we
   do not end up doing (1), if upstream introduces a keyword-mute feature
   that also uses a "KeywordMute" model, we can avoid some merge
   conflicts this way and work on the more interesting task of
   choosing which implementation to use.

Also add a destroy-all action, which can be useful if you're flushing an
old list entirely to start a new one.

This should eventually be accessible via the API and the web frontend,
but I find it easier to set up an editing interface using Rails
templates and the like.  We can always take it out if it turns out we
don't need it.