[libharu,wt] Update libharu to 2.4.2 and Wt to 4.8.1

[RockinRoel]

• What does your PR fix?

  Updates libharu version to 2.4.2 and Wt version to 4.8.1.

• Which triplets are supported/not supported? Have you updated the CI baseline?

  libharu builds on all of them, for Wt the triplets should stay the same as before:

  • x64-linux
  • x64-osx
  • x64-windows
  • x64-windows-static
  • x86-windows

  It turns out UWP flavors don't build because of the Boost Filesystem dependency, and on my machine arm64-windows fails when building glew.

• Does your PR follow the maintainer guide?

  Mostly, some remarks:

  • I can't split this up in separate PRs since older versions of Wt don't compile with libharu 2.4.x.
  • libharu 2.4.2 changed the target name from haru to hpdf, but I used EXPORT_NAME to keep it the same as it was before. If desired I could change it to unofficial::libharu::hpdf, but then all ports that depend on it require fixing.
  • poco[pdf] appears to be broken (the PocoPDF library is not built or installed). I did not address this with this PR.

• If you have added/updated a port: Have you run ./vcpkg x-add-version --all and committed the result?

  Yes

[dg0yt]

• libharu 2.4.2 changed the target name from haru to hpdf, but I used EXPORT_NAME to keep it the same as it was before. If desired I could change it to unofficial::libharu::hpdf, but then all ports that depend on it require fixing.

We should not touch the new target names. To avoid patching downstream vpckg ports, we should just add an interface library with the old name to CMake config file.
This must be complemented by a usage file which shows the proper new CMake usage.

[RockinRoel]

• libharu 2.4.2 changed the target name from haru to hpdf, but I used EXPORT_NAME to keep it the same as it was before. If desired I could change it to unofficial::libharu::hpdf, but then all ports that depend on it require fixing.

We should not touch the new target names. To avoid patching downstream vpckg ports, we should just add an interface library with the old name to CMake config file. This must be complemented by a usage file which shows the proper new CMake usage.

I added an interface library and a usage file. I hope I did everything correctly.

[Cheney-W]

Old usage:

find_package(unofficial-libharu CONFIG REQUIRED)
target_link_libraries(main PRIVATE unofficial::libharu::haru)

New usage:

find_package(unofficial-libharu CONFIG REQUIRED)
target_link_libraries(main PRIVATE unofficial::libharu::hpdf)

[RockinRoel]

I updated the usage file.

[Cheney-W]

I'm sorry to mislead you, what I meant was that the updated usage has changed, which may affect the results of other ports when using libharu, which in turn will lead to the need to make the appropriate changes, just as you did with the vtk changes. But in practice we don't want the port itself to be modified to affect downstream.

[RockinRoel]

So do you need me to make special mention of it in libharu's usage file, or do I just mention the latest usage?

I have now used an imported target to maintain compatibility, so I think the autogenerated usage string will mention both instead of just the one they're supposed to use. Do I keep it like that or do I remove the imported target?

[Cheney-W]

I've discussed this with others and since the usage for this port is one that we provide, it's an unofficial one, so if something changes here and affects downstream, then it does require going and manually modifying the downstream using to match the new usage, so you don't need to make any changes, the current usage is fine.