DXMT: fix the supported LLVM 15 build

[moreaki]

Summary

Fix the in-tree DXMT build against the LLVM 15 toolchain used by the supported macOS/Arm path.

The patch is deliberately limited to build/link compatibility:

• ask the configured llvm-config for the LLVM libraries and library directory;
• preserve the existing static component-library list as a fallback for VirtualBox devtools trees without llvm-config;
• include the standard allocation declarations required by current Apple Clang.

It does not rewrite DXMT for LLVM 17 or newer APIs.

Why

Hard-coded component archive paths do not match packaged LLVM installations that expose a shared libLLVM. Conversely, Oracle/devtools layouts may not ship llvm-config, so the existing static link remains necessary as a fallback.

Validation

• Rebased and applied independently to current origin/main.
• git diff --check passes.
• A clean VBoxDxMt target build succeeds with Homebrew LLVM 15.0.7.
• The integrated full build also produces VBoxDxMt.dylib.
• otool -L VBoxDxMt.dylib resolves /opt/homebrew/opt/llvm@15/lib/libLLVM.dylib with current version 15.0.7.

Refs #742.

[oracle-contributor-agreement]

Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA).
The following contributors of this PR have not signed the OCA:

• PR author: moreaki
• rnibali@gmail.com (@moreaki)

To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application.

When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated.

If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public.

[moreaki]

I checked DXMT v0.80 before deciding whether this PR should instead be replaced by a vendored DXMT update.

Result: v0.80 does not make this compatibility patch obsolete. It includes the separate CPU encoding heap fix from upstream DXMT, but it still has LLVM API drift in the AIR converter code:

• src/airconv/nt/air_builder.cpp syntax-checks with LLVM 15 headers, but fails with LLVM 16/17 headers on llvm::Attribute::AttrKind::ArgMemOnly.
• With LLVM 22 headers it also fails on removed typed-pointer APIs such as getNonOpaquePointerElementType() and renamed/removed attributes such as NoCapture.
• The legacy converter path syntax-checks with LLVM 15/16 headers, but LLVM 17 fails on the removed llvm/ADT/Optional.h include.
• DXMT v0.80 still carries fixed LLVM component library lists in its Meson build files, so the VirtualBox kBuild llvm-config handling remains a separate build-system compatibility fix.

So a future DXMT v0.80 vendor refresh may still be valuable, but it would need its own follow-up LLVM compatibility work for the newer nt/ AIR converter paths. It is not a drop-in replacement for this PR against the current DXMT 0.60 vendor snapshot.

[moreaki]

DXMT v0.80 audit update:

Updating the vendored DXMT tree to v0.80 would not currently remove the need for the source-compatibility parts of this PR. I checked DXMT v0.80 (589adb7) and current DXMT main (73d42c5); both still contain LLVM API uses such as Attribute::AttrKind::ArgMemOnly, getNonOpaquePointerElementType(), llvm::Optional, and related LLVM-version drift in the AIR conversion code.

I opened the upstream DXMT source-compatibility issue here: 3Shain/dxmt#185

The VirtualBox Makefile.kmk llvm-config portion remains a downstream integration fix for the vendored/kBuild tree. DXMT upstream also has an analogous hard-coded Meson LLVM link-list issue, so I opened that separately upstream:

• Native build fails with Homebrew LLVM 15 on Apple Silicon 3Shain/dxmt#192
• build: support Apple Silicon Homebrew LLVM 3Shain/dxmt#193

If VirtualBox later imports a DXMT version that resolves those upstream items, this PR can be reduced or replaced accordingly.