Recent changes in the completion highlighter mandate that
config.val.colors.completion.match be changed from a QssColor to a
QtColor. However, the latter accepts fewer formats. To avoid breaking
configs, this allows QtColors to be specified using all the same formats
as QssColors, excluding gradients.
I separated the QssColor and QtColor tests as the previous approach of
generating the tests made adding tests for QtColor more complicated.
While working on this I discovered that Qt's css parser is potentially
broken around parsing hsv percentages and filed
https://bugreports.qt.io/browse/QTBUG-70897.
For consistency, I made our parser similarly broken.
You can show the bug in qutebrowser right now by noting that the
following have different effects:
```
set colors.completion.odd.bg 'hsv(100%, 100%, 100%)'
set colors.completion.odd.bg 'hsv(358, 255, 255)'
```
This is a more "Qt" way of highlighting syntax, and works around the
problems of #4199 without resorting to complicated html escaping.
The tests are more straightforward with less mocking, but do involve
testing a private class.
This exposes all possible values, but before
https://codereview.qt-project.org/#/c/240121/ we won't be able to change those
at runtime (or enable URL patterns, which thankfully weren't enabled for the
old setting).
In theory, it'd be possible to handle the "public-interface-only" value via
QWebEngineSettings without requiring a restart, but it isn't worth the trouble.
Closes#4201
In Qt < 5.10 (and also sometimes on Windows), we get extra spaces or newlines
when moving to the end of the document. However, this only happens *sometimes*,
and manual testing confirms that with the current workaround, we actually lose
the last char in the selection.
I'm not sure what's happening there, but instead of making things worse with
the workaround, let's just be a bit less strict with the checking there and
accept both variants... This seems like some Chromium bug we can't do much
about.
