ENH: Modernize CMake packaging to match vtkAddon (supersedes #27)

[RafaelPalomar]

This supersedes #27 and builds on it: it keeps that PR's install/config rework and brings qRestAPI's CMake packaging in line with vtkAddon, the reference project for Slicer-family libraries. The goal is a library that installs cleanly and can be consumed standalone (e.g. building Slicer with SUPERBUILD=OFF, or via distro/homebrew packaging).

What changes

• Export an imported qRestAPI target for both the build tree and the install tree through install(EXPORT). Downstream projects link the target and inherit include directories transitively, so UseqRestAPI.cmake / qRestAPI_USE_FILE are no longer needed and are removed.
• Generate the install-tree package config with configure_package_config_file(), making installed trees relocatable (no absolute CMAKE_INSTALL_PREFIX is baked in).
• Declare include directories as PUBLIC usage requirements (BUILD_INTERFACE / INSTALL_INTERFACE) and link Qt with explicit visibility.
• Keep the legacy qRestAPI_INCLUDE_DIRS, qRestAPI_LIBRARY_DIRS and qRestAPI_LIBRARIES variables for backward compatibility.
• Document the install/packaging variables in the README.

Consumers that relied on qRestAPI_USE_FILE must drop it and link the qRestAPI target instead (a matching one-line change is needed in Slicer's Base/QTCore).

Location of the config templates

The predecessor PR was discussed at the Slicer developer weekly meeting on 2026-07-07, where @lassoan suggested moving the CMake config files under a CMake/ directory rather than leaving them at the project root.

This PR keeps the *Config.cmake.in templates at the root. The rationale is consistency with vtkAddon, where the root holds the public package-config templates while CMake/ is reserved for build-helper modules (macros, wrap scripts). The placement is functionally neutral — the template path is given explicitly to configure_file() and is not affected by CMAKE_MODULE_PATH — so matching the reference project is the deciding factor. Happy to move them under CMake/ if the preference stands.

qRestAPI_INSTALL_NO_DEVELOPMENT kept as a plain variable

@ferdymercury suggested (in #27) promoting this to a cache option. This PR keeps it as an if(NOT DEFINED ...) default, primarily for consistency with vtkAddon and other Slicer-family libraries, which use the same pattern for their install-layout variables. The functional difference is small; the main trade-off of not using a cache option is reduced discoverability in cmake-gui, which is addressed by documenting these variables in the README. This is a convention call rather than a technical constraint — happy to discuss a change on this with the devs.

---

This PR was prepared with the help of Claude Code (Opus 4.8).

[ferdymercury]

Thanks a lot for this, looks promising

which is addressed by documenting these variables in the README

Sounds good. Could apply a similar Readme update PR on Slicer/vtkAddon#70 so that it's documented there too, for consistency?

[lassoan]

Thank you, this looks good to me.

Would it be possible to add an option for ${PROJECT_NAME}_INSTALL_NO_DEVELOPMENT?

• It is the standard way of telling that it is a public configuration variable.
• It would allow setting a default value, so we could avoid the awkward double-negative: instead of qRestAPI_INSTALL_NO_DEVELOPMENT=OFF we could simply have qRestAPI_INSTALL_DEVELOPMENT=ON.
• Its documentation would show up both in the CMakeLists.txt file and in the CMake GUI (you would not need to go anywhere else for documentation and the risk of documentation and implementation getting out of sync would be lower).

Consistency is useful, so we could fix this negative naming and lack of option defintion in vtkAddon, before it spreads to too many places.