[CMake] Support builds with CMAKE_BUILD_WITH_INSTALL_RPATH=ON and gnuinstall=ON

[guitargeek]

This follows up on guitargeek@e0f8cbc, implementing a more elegant solution
for the problem in #19327, which is now better understood.

The problem was the interaction between my commit guitargeek@c77bd87 in the
6.36 development cycle, the CMAKE_BUILD_WITH_INSTALL_RPATH=TRUE option that
is set by the MacPorts build system, and the gnuinstall=ON option.

In case of gnuinstall=ON, the install tree directories are different
form the build tree directories, in particular the relative path from
the binary to the library directory. The correct RPATH values are
inferred from this relative path. Now, when the user sets
CMAKE_BUILD_WITH_INSTALL_RPATH=TRUE at configuration time, CMake uses
the RPATHs for the install tree also for the build tree, which is not
correct. The build of ROOT will fail, because rootcling doesn't have
the right RPATH, and rootcling is used during the build.

Two mechanisms in the ROOT CMake code were in place to guard against
this problem.

1. The LD_LIBRARY_PATH is set in the rootcling calls during the
   build, on Linux the build would have succeeded. But on macOS, is was
   forgotten to use DYLD_LIBRARY_PATH, which was not done correctly
   until recently with guitargeek@e0f8cbc.

2. Another way how ROOT worked around this RPATH consistenty problem was to
   simply set CMAKE_BUILD_WITH_INSTALL_RPATH=FALSE, no matter what the
   user wants. I thought overriding these global CMAKE_* parameters that
   are quite useful for the users is not good practice, so I removed that
   in guitargeek@c77bd87.

So mechanism 1 failed because of macOS, and mechanism 2 failed because I
removed it.

Now that I understood the real problem, this commit implements the
proper solution: override the global CMAKE_BUILD_WITH_INSTALL_RPATH
only for the rootcling target, so that it can be used during the build
successfully.

This means we can also remove the mechanism 1 that set the library path
for rootcling during the build, as the RPATH is now guaranteed to be
correct. Removing that mechanism makes the CMake code more homogeneus
with the Windows version, since setting the library path on Windows is
not necessary.

[github-actions]

Test Results

    21 files      21 suites   3d 22h 12m 55s ⏱️
 3 645 tests  3 494 ✅  0 💤 151 ❌
74 804 runs  74 630 ✅ 23 💤 151 ❌

For more details on these failures, see this check.

Results for commit 3183c29.

♻️ This comment has been updated with latest results.

[bellenot]

So on Windows, the DLLs are found in the PATH env variable, like any other executable.

[bellenot]

LGTM, thanks!