Fix problem with static link order with static clang and llvm

[mppf]

This resolves a problem on CentOS 7 which has an error like this:

: CommandLine Error: Option 'enable-vfe' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options

We have some evidence that this error was caused by statically linking LLVM libraries but dynamically linking clang-cpp. For one thing, on that system, changing to statically linking both solved this issue.

This PR changes chpl_llvm.py to ask llvm-config if it has shared libraries available (with llvm-config --shared-mode) and if not it will use the static linking approach for both the LLVM and clang dependencies.

Additionally, when using static linking for LLVM and clang, on CentOS 7, the linker was picky about the order. Since the link line should have the things depended upon later, this PR puts the -l flags for clang libraries before the -l flags for LLVM libraries. On Mac OS X with Homebrew LLVM, we were using the same (arguably incorrect) -l ordering but for some reason the linker there did not complain.

Note that we statically link both LLVM and clang on Mac OS X (since PR #18727). This PR leaves it this way. Historically, there have been problems with upstream LLVM and Homebrew in building a dynamic library that works with llvm-config (in particular the versioned file, like libLLVM-11.dylib, is missing). See this LLVM bug report. I expect that we will be able to allow dynamic linking on Mac OS X once we are able to establish that the issue is resolved.

We are statically linking with CHPL_LLVM=bundled and this PR does not change that.

Reviewed by @Maxrimus - thanks!

• 'hello' builds and runs with system LLVM on Ubuntu 21
• 'hello' builds and runs with system LLVM on SLES 12
• 'hello' builds and runs with system LLVM on Mac OS X with Homebrew
• 'hello' builds and runs with bundled LLVM on Ubuntu 21
• full local testing

[Maxrimus]

LGTM

[Maxrimus]

Got a success of the python-modules job running on this branch