Optionally use QML

[KitsuneRal]

It is well-known that uMatriks, Tensor and Quaternion have duplicating code, and it would be great if it were collected into a separate library. libqmatrixclient, though, strives to target (still missing) non-QML uses as well, and therefore avoids having a dependency on QML. There are two options to go forward with this:

1. The long-considered, still-not-implemented naive way: make one more library, called libqmatrixclient-qml or even libqmatrixclient-gui. This library would itself depend on libqmatrixclient, so building clients on top of it instead of libqmatrixclient would be more or less a drop-in replacement. The downside is that housekeeping costs almost double: it's one more submodule (and for a client, it will be nested, which is a usual source of surprises with people forgetting to add --recursive where necessary), with one more GitHub repo; boilerplate code in CMakeLists.txt, Travis/AppVeyor files etc. replicates once again. Besides, this does not address some cases where QML dependency is especially pervasive - e.g. using a special container class template, QQmlListProperty<>, is recommended when exposing a QList<>-based list of QObject-based objects as a Q_PROPERTY. With a separate GUI library it means that to expose, e.g., the list of room members the GUI library needs to derive from QMatrixClient::Room and make a QML-friendly Q_PROPERTY outside of libqmatrixclient or to just give up using property binding with this property.
2. Add QML to libqmatrixclient as an option. Depending on the build tool, it would be either --with-qml argument or USE_QML CMake option. The QML-related code can be packed up in a separate directory as much as possible. The downside is that Linux distributions will either have to provide the full (with QML) version or do non-trivial stuff to make the two flavours of the library live on the same system without confusing dynamic linkage of client applications. But my experience tells that's something Linux distributions solve on a routine basis; and aside from very margin cases, we can mandate that compiling a non-QML application with QML-flavour of libqmatrixclient should still succeed - then a single QML-enabled dynamic library will serve both QML and non-QML applications. Another downside, of course, is that it becomes very easy to contaminate 'pure' libqmatrixclient with QML - this can be solved by setting up CI to build libqmatrixclient in both configurations, with QML only available where it's needed.