Draft: Make internal includes work independent of the include search path(s)

[vkrause]

This is necessary in order to be able to remove include/Quotient from the include search path to force namespaced includes in consumer code.

This is still vastly incomplete on the non-generated header files, so consider those only as an example. The real blocker however are the includes to referenced types in the generated headers.

[KitsuneRal]

The more I look at it, the more I think of "just" renaming the sources folder lib to Quotient so that all headers could use either #include "Quotient/...." or #include <Quotient/....>, depending on the context. That is not backwards-compatible, of course, but less of a hassle for generated headers in particular.

[vkrause]

The more I look at it, the more I think of "just" renaming the sources folder lib to Quotient so that all headers could use either #include "Quotient/...." or #include <Quotient/....>, depending on the context. That is not backwards-compatible, of course, but less of a hassle for generated headers in particular.

This can be done in a source-compatible way as well I think, if we assume consumer code uses either our CMake config file or the pkgconfig file. There we can add $prefix/Quotient to the search path as well, so consumer code keeps working (with an opt-out option for consumer code that uses namespaced includes everywhere). If that's acceptable I can work into that direction as well.

[KitsuneRal]

Yes, thanks, let's go in this direction. Meanwhile, I updated GTAD a bit to normalise include paths. This is not directly helping anything on the current issue, so JFYI.

[KitsuneRal]

Preempted by #626.