Bug#1018004: qt6-tools: does not build and link with system litehtml

[Rob Savoury <savoury@savos.tech>]

Hi Lisandro,

It's a good suggestion about doing a MR using Salsa in future, an
option that I didn't consider (three years ago I did make a Salsa
account for one task with another package, so an MR is possible).

There are actually two issues here. A key one is certainly with the
missing litehtmlConfig.cmake file, which I did actually mention in
the first paragraph of the bug report. So until litehtml is updated
it does block this bug being resolved.

However, there is another issue with qt6-tools CMake logic causing
the CMake configure phase to error out when trying to build with a
system litehtml package. Here are the errors (can be confirmed by
attempting to build qt6-tools with a version of litehtml that does
include litehtmlConfig.cmake):

```
CMake Error at
/usr/lib/x86_64-linux-gnu/cmake/Qt6/QtFlagHandlingHelpers.cmake:171
(target_compile_definitions):
  Cannot specify compile definitions for target "litehtml" which is
not built
  by this project.
Call Stack (most recent call first):
  src/assistant/CMakeLists.txt:34 (qt_internal_set_exceptions_flags)


CMake Error at
/usr/lib/x86_64-linux-gnu/cmake/Qt6/QtFlagHandlingHelpers.cmake:190
(get_target_property):
  get_target_property() called with non-existent target "litehtml".
Call Stack (most recent call first):
  src/assistant/CMakeLists.txt:35 (qt_disable_warnings)


CMake Error at
/usr/lib/x86_64-linux-gnu/cmake/Qt6/QtFlagHandlingHelpers.cmake:190
(get_target_property):
  get_target_property() called with non-existent target "gumbo".
Call Stack (most recent call first):
  src/assistant/CMakeLists.txt:37 (qt_disable_warnings)
```

These errors cause FTBFS unless src/assistant/CMakeLists.txt in
qt6-tools is also patched. In the patch I attached to this bug
report is then a proposed patch to include in qt6-tools package.

The proposed patch to include in qt6-tools package simply removes
the three offending CMake commands that cause the above quoted
errors. So it appears to be an upstream bug with CMake logic used by
qt6-tools as well (though I haven't filed a bug with Qt directly yet
as I first wanted to report it here). It seems that upstream does
not properly cater to using a system litehtml library after all.

Also a change to the header path for litehtml will be required if a
version of litehtml > 0.5 is packaged by the maintainer due to newer
litehtml moving headers into a litehtml directory. Thus, the patch
that I proposed to include in qt6-tools would also modify this file:

src/assistant/qlitehtml/src/container_qpainter_p.h

The header path in that file would be changed from litehtml.h to
litehtml/litehtml.h as per litehtml > 0.5 source.

Therefore it does certainly seem easier just to use the litehtml
source included in qt6-tools in the end! However, as litehtml is
already packaged in Debian and given that qt6-tools has a BD on
liblitehtml-dev that was not actually being used it is indeed a bug
(and with both packages, as explained above). At least in terms of
the intended outcomes! So that's why I filed the two bug reports.