Having a ::new on each of the filter types was a bit weird, especially
because we returned Box<dyn ...> instead of Self (and clippy rightfully
complained). With this patch, we now have a bunch of normal functions,
and we don't show to the outside how a filter is actually implemented
(or what struct is behind it).

Since our predicates start with -, this sounds like a good heuristic to
prevent something like "raidgrep -- -player" from silently succeeding
but not doing what the user had intended. In this case, we want the
parse error to show and not treat "-player" as a regex.

First, this commit adds a shortcut if only a single argument is given
that can be parsed as a regex. This is to retain the old behaviour of
"raidgrep NAME" just working, without needing to specify -player or
anything.

Secondly, this also re-wraps arguments with spaces (unless there's only
one argument in total). This means that the following should work:
    raidgrep -- -player "Godric Gobbledygook"
instead of either
    raidgrep -- '-player "Godric Gobbledygook"'
    raidgrep -- -player '"Godric Gobbledygook"'
(notice the extra quotes).

Sadly, structopt always displays this, despite the documentation stating
that it should be hidden when the user uses -h (instead of --help). It
seems like this is a bug in clap, which might get fixed with clap 3.0.

This gives us a history, nicer editing capabilities and the possibility
to add completion in the future.

If we don't allow the higher-tier on the left side, we cannot chain
multiple or/and on the same level. Since or is associative, we shouldn't
expect the user to write (... or (... or ...)) and instead provide the
flattened version as well.