The current regular expression is able to match `/usr/lib/<arch>`,
`/usr/usr/lib/<arch>`, `/usr/usr/usr/lib/<arch>`, ... but not
`/lib/<arch>`.
This behavior ends up causing the detected architecture to
be x86_64-pc-linux-gnu when the Clang compiler is installed on
a "non-system" location (like /opt/llvm-13) which, in turn, makes
almost every 'find_library()' fail because the correct
architecture is x86_64-linux-gnu.
This is due to a typo in commit 764606e256 (CMakeDetermineCompilerABI:
Extract lib arch from implicit object file paths, 2021-04-05,
v3.20.1~10^2), which used `+` instead of `?`.
The NVHPC compiler does not have any implicit link directories that can
be used to detect `CMAKE_LIBRARY_ARCHITECTURE`, but it does have
implicit object files. Extract implicit object file paths from link
lines and check them for the `CMAKE_LIBRARY_ARCHITECTURE` pattern.
Issue: #22024
The change in commit 657fc3a9a7 (CMakeDetermineCompilerABI: Parse
library arch from versioned paths, 2021-02-03, v3.20.0-rc1~40^2) caused
`CMAKE_LIBRARY_ARCHITECTURE` to be populated on non-multiarch platforms
if their compilers happen to use `$arch/$version` library directories.
Revert the use of versioned library paths.
Fixes: #22024
Teach CMake how to extract `CMAKE_<LANG>_LIBRARY_ARCHITECTURE` from
versioned paths such as `/usr/lib/gcc/x86_64-linux-gnu/9`. These kind of
paths are generated by NVHPC compilers.
