ELDExpectedUsage test binary, target-specific wrappers end up in the wrong build location when LLVM is invoked as a subproject

[jonathonpenix]

Description
When llvm is invoked as a subproject, the target-specific wrappers (riscv-link, etc.) and tests/ELDExpectedUsage end up in unexpected places for the build (the final install looks ok I think). See the example below (the linker wrappers end up in ./build/bin rather than ./build/llvm/bin)

This isn't the end of the world (I don't think the target-specific wrappers being in a different spot causes any direct issues besides being a bit confusing), but does cause test failures for ELDExpectedUsage (see Comments section below).

Invoking LLVM as a subproject can be helpful when assembling a full toolchain--this is how ex: Arm's toolchain and the Zephyr SDK (which is based off an older version of the Arm toolchain) work. We've also considered similar things for cpullvm. So, I think it is might be worth trying to fix this to support this sort of use case.

Reproducer

cat > CMakeLists.txt << '!'
cmake_minimum_required(VERSION 3.16)

project(example)

set(LLVM_ENABLE_PROJECTS clang;lld CACHE STRING "")
set(LLVM_TARGETS_TO_BUILD AArch64;ARM;RISCV CACHE STRING "")
set(LLVM_ENABLE_LIBCXX ON CACHE BOOL "")

set(llvmproject_src_dir ${CMAKE_CURRENT_SOURCE_DIR}/llvm-project)
set(LLVM_EXTERNAL_PROJECTS eld)
set(LLVM_EXTERNAL_ELD_SOURCE_DIR ${llvmproject_src_dir}/eld)

add_subdirectory(
    ${llvmproject_src_dir}/llvm llvm
)
!

cmake -G Ninja \
     -DCMAKE_BUILD_TYPE=Release \
     -DCMAKE_C_COMPILER_LAUNCHER=ccache \
     -DCMAKE_CXX_COMPILER_LAUNCHER=ccache \
     -DCMAKE_INSTALL_PREFIX=$PWD/install \
     -B $PWD/build \
     -S .

cmake --build build

# ld.eld ends up in ./build/llvm/bin with *most* of the rest of the llvm binaries/utilities.
# It seems scan-build also has similar issues here?
ls ./build/llvm/bin

# The target-specific wrappers (riscv-link, etc.) and `tests/ELDExpectedUsage` end up in
# `build/bin/` instead
ls ./build.bin

# Common/standalone/PluginAPI/ELDExpected.test fails with this error:
#   /path/to/build/llvm/bin/tests/ELDExpectedUsage /path/to/build/llvm/tools/eld/test/AArch64_default/Common/standalone/PluginAPI/Output/ELDExpected.test.script: line 1: /path/to/build/llvm/bin/tests/ELDExpectedUsage: No such file or directory
ninja check-eld

Comments
I think this originates here as ${CMAKE_BINARY_DIR} will always point to the "top" of the cmake build tree.

For the ELDExpectedUsage test failure specifically, I think the issue is just that there is a mismatch between the CMAKE_BINARY_DIR-relative path and what I think boils down to a LLVM_BINARY_DIR-relative path in ELDExpected.test

CMAKE_RUNTIME_OUTPUT_DIRECTORY actually looks in the direction of what we'd want here? I haven't looked at why exactly it wasn't used in the first place. LLVM has some similar-looking-to-eld's-comments on this, see ex: set_output_directory (where using CMAKE_RUNTIME_OUTPUT_DIRECTORY is recommended against).