Keep the almost sorted list around and sort by the raw timestamp value
instead of doing the expensive toMSecSinceEpoch conversion.

Sometimes thumbnails still have the wrong dimensions, as they are scaled
to fit inside a rectange of the reported size in the image. Not sure,
who is wrong there, the media repo or we.

fixes #172

This may increase the db size by a factor of 1000 in the worst case and
it will need some fixes, when we decide to not show some events in the
timeline, but it should work for now.

Also lays a bit of groundwork for better reply rendering

This also makes long messages unreadable, because we don't shorten long
usernames anymore. We may eventually want to do that again, but it is
hard with translations and we probably want to shorten the displayname
more, as before this change the message was only ever as long as the
timestamp, which is usually just 5 characters...

On first launch, before the user has configured any settings,
check the value of the QT_QPA_PLATFORMTHEME environment var.
If it is set, use the system theme as the default instead of the
light theme.  This fixes #72.

I'm not sure, if that is the right way, but Qt doesn't really have a way
to format custom localised dates, so I tried to find the closest
approximations to what we currently have.

Relates to #69

Update to mtxclient 0.3.0

Quoted replies now include matrix.to links for the event and the user.
UI Rendering has been (slightly) improved... still very WIP.
Restructured the reply structure in the code for future usability
improvements.

Parsing html as xml has inherent problems, most notable there are many
matrix clients that don't escape ampersands in urls of mx-replies, etc.
(See issue #18)

This also removes the replacement of <mx-reply> as it isn't strictly
needed.

Also the QRegExp is replaced with the Qt5 QRegularExpression for
perfomance and because it supports lookahead and lookbehind.

I'm pretty sure that the original code also replaced href="" with
href=\"\", which was probably wrong, but I'm not to sure about that.

Fixes #18

Colors are generated asynchronously now and the TimelineItem is
updated when the color generation finishes.  This allows the UI
to stay responsive while new colors are being generated.

User colors are now stored in cache.  This is consistent
with other similar variables.  I think there's a bug
right now where it doesn't properly refresh colors
for the TimeLineItem when the theme is changed.

Author color is now cached so that it will not be re-calculated
each time a new message is posted.  This cache gets cleared when
the theme is changed.

Additionally, the author color is now automatically refreshed
when the theme is changed, fixing the issue where you had to
change rooms before the colors would switch.

Update the author color generation.  Now, instead of generating
an entire hex string based on the user id, the user id instead
is used to generate a hue value.  After this hue value is created,
there is some logic to tweak first the lightness and then saturation
values to achieve a readable color (in contrast to the background).

This change makes it so that user colors will not vary as wildly
between the different themes.

The values still are not cached and still do not update
initially when the theme is changed.  Both of these things
will be resolved.

work regardless of the theme choices the user makes.  The code
now incorporates the contrast between the background color and the
color generated by the user_name when picking colors.  It currently
has two 'big' issues:
1. Colors are not cached.  I am planning on adding a QHash for this
a little later.  This should improve performance by not calculating
the color for the same users over and over and over again.
2. Theme changes do not trigger the colors to get refreshed.
Currently, you will have to switch to a different room and back
to get the colors to refresh.