Do not install CMake config files in a different directory on Windows

[traversaro]

A small cleanup that would make sense to get in urdfdom 4.

CMake config files were installed in a different directory in #41 as a workaround for a CMake issue on discoverability of packages installed in the default Windows install prefix (https://gitlab.kitware.com/cmake/cmake/issues/16212) that was fixed in CMake 3.7 (https://gitlab.kitware.com/cmake/cmake/-/merge_requests/68), so the workaround is not necessary when using CMake >= 3.7 (released ~7 years ago). Note that install on CMake <= 3.7 continues to work fine, the only thing that does not work is finding automatically a urdfdom installed in the default install prefix.

This PR removes the workaroud, and installs CMake config files in the same location for all OS, i.e. ${CMAKE_INSTALL_LIBDIR}/${PROJECT_NAME}/cmake . It is convenenient to have this merged before urdfdom 4 because:

• This change has the minor downside that it breaks any process that hardcodes the location of the CMake config file, tipically build recipes such as the one used in vcpkg (https://github.com/microsoft/vcpkg/blob/16ee2ecb31788c336ace8bb14c21801efb6836e4/ports/urdfdom/portfile.cmake#L26) or conda-forge (https://github.com/conda-forge/urdfdom-feedstock/blob/9c46e275a0e8148a920933d9ef2660145ac4672a/recipe/meta.yaml#L47). Hence, it is convenient (even if probably not strictly necessary) to do this in a major release.
• This changes ensure that the TinyXML2.cmake installed in Upgrade from tinyxml to tinyxml2 #186 is installed in a project-specific location also on Windows.

fyi @clalancette

[clalancette]

I've rebased this onto the latest now that #186 is merged. Assuming the PR jobs above succeed, I'll also run ROS 2 CI on this.

[clalancette]

CI:

• Linux
• Linux-aarch64
• Windows
• Windows Debug