QPID-7148: Use more modern CMake install machinery for better QpidConfig.cmake

[jiridanek]

Turns out, CMake is happy to generate a lot of the QpidConfig.cmake file for us, see

• https://gitlab.kitware.com/cmake/cmake/-/issues/19560
• https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-packages
• https://cmake.org/cmake/help/latest/guide/importing-exporting/index.html#exporting-targets
• https://cmake.org/cmake/help/latest/module/CMakePackageConfigHelpers.html#example-generating-package-files
• https://cmake.org/cmake/help/latest/guide/tutorial/Packaging%20Debug%20and%20Release.html

This is analogous change to PROTON-2254 for Qpid Proton.

[jiridanek]

TODO

• Check this solves my problems in downstream project, https://github.com/rh-messaging/cli-cpp
• Check that Windows build (with the d versions for debug DLLs) is still working

[jiridanek]

It appears that this really fixes the build for me rh-messaging/cli-cpp#71

The issue is that Bazel moves the installed library around, and requires QpidConfig.cmake to contain relative paths. Otherwise, attempt is made to fetch libraries from original install location, which is prevented by Bazel sandbox and therefore build fails.

[jiridanek]

As far as I can remember, federation tests are broken and failure can be ignored

6: federation.FederationTests.test_dynamic_direct_shared_queue ............. fail
6: Error during test:  Traceback (most recent call last):
6:     File "/home/travis/.local/bin/qpid-python-test", line 340, in run
6:       phase()
6:     File "/home/travis/build/apache/qpid-cpp/Build/src/tests/federation.py", line 2592, in test_dynamic_direct_shared_queue
6:       self.assertNotEqual(_c.msgsToClient, 0, "Messages did not pass over link as expected.")
6:     File "/usr/lib/python2.7/unittest/case.py", line 522, in assertNotEqual
6:       raise self.failureException(msg)
6:   AssertionError: Messages did not pass over link as expected.

https://app.travis-ci.com/github/apache/qpid-cpp/builds/256978344#L2108