Refactor the way device backends are built and registered

Summary:
Currently, the bits of information of each device backend (e.g. udev,
upower, etc) are spread in different files:

• their sources in each CMakeLists.txt
• their libraries in the CMakeLists.txt that assembles the devices part of libKF5Solid
• their cmake bits in different places

Also, the logic for building the backends in the library, and then
registering them in the DeviceManager, are repeated as cmake, and C++
bits, with small differences between them.

To overcome these limitations, introduce a set of cmake macros, and
functions to deal with the addition of a device backend:

• a single place, in the top-level CMakeLists.txt, determine which backends are built
• the CMakeLists.txt of each backend has just their sources (with no paths), and their libraries needed too
• the cmake bits create a config-backends.h file with the #define's of the enabled backends
• the cmake bits set cmake variables, so other cmake bits can perform other operations depending whether a backend is built
• the backends are registered in the DeviceManager depending solely on the fact that they are built
• there is a new cmake option() variable to disable the build of a backend
• the cmake feature_info stuff is used to show which backends are enabled, in a more visibile way

Test Plan:

• build solid
• check that the enabled backends are the same as before (see the list in the cmake output for enabled features)
• check that the reported devices are the same as before

Subscribers: Android, Windows, FreeBSD, apol, kde-frameworks-devel

Tags: Frameworks

Differential Revision: https://phabricator.kde.org/D17991