[clang] [Clang][Driver][AArch64] Add support for aarch64-amazon-linux triple (PR #109263)

[Peter Waller via cfe-commits]

peterwaller-arm wrote:

>So what should we (Amazon Linux) do to help with this ? 

What I think is needed is:

* Public consensus on how to detect the triple (or at least the vendor) on Amazon Linux. This would help coming from you.
* Consensus on how/when to insert the triple into `LLVM_INFERRED_HOST_TRIPLE`.

> `LLVM_DEFAULT_TARGET_TRIPLE` if unspecified comes from `LLVM_INFERRED_HOST_TRIPLE` which comes from config.guess in here: https://github.com/llvm/llvm-project/blob/592adb0b24aca2ccc88d9f5f1c427361897d1172/llvm/cmake/modules/GetHostTriple.cmake#L49

I don't know enough about the history of the current GetHostTriple and the fact it calls into the (long) GNU-licensed vendored config.guess file.

My guess is that a solution should continue to use the existing config.guess; but that would need to be fixed by someone else in https://git.savannah.gnu.org/cgit/config.git/ and then the vendored copy updating. It seems to me this is the cleanest minimal solution (which will also fix other things), but it assumes config.guess is here to stay in the LLVM repository. If not, then an alternative method would be to add logic to GetHostTriple cmake file linked above to determine the triple without use of config.guess [0]. There is also the possibility of a hybrid solution of patching the triple coming out of config.guess to insert the vendor but that would seem to be adding to the mess, so I assume that's a non-starter.

[0] I'm not sure how; maybe it's as simple as checking for or enumerating some paths, but I'm not sure we ideally want to be 'in the limit' adding many path checks during configure time either. If only there existed a `/etc/triple` that could be read.

https://github.com/llvm/llvm-project/pull/109263