Handle externalwarnings in the clang toolset

[NotAFlightRisk]

What does this PR do?

clang.shared follows gcc.shared entry by entry, either delegating to it or overriding it with something clang specific. externalwarnings is the one exception: gcc has the mapping, clang has neither.

So externalwarnings "High" is silently ignored under toolset "clang". externalincludedirs still emits -isystem<dir>, so warnings from vendored headers are supressed, and the option ment to turn them back on emits nothing at all. Nothing tells you the setting was dropped.

How does this PR change Premake's behavior?

Clang now uses gcc's externalwarnings mapping. Clang accepts -Wsystem-headers, so the option can do what it says.

With externalincludedirs and externalwarnings "High" set on a gmake project, here is the line each toolset generated:

gcc: ALL_CXXFLAGS += $(CXXFLAGS) $(ALL_CPPFLAGS) -Wsystem-headers -Wall

clang: ALL_CXXFLAGS += $(CXXFLAGS) $(ALL_CPPFLAGS) -Wall

After the change clang gets -Wsystem-headers too. Existing behaviour only moves when externalwarnings is actualy set for clang or emcc.

Anything else we should know?

premake5 test passes all 2903 tests from 232 suites. Before the fix cflags_onHighExternalWarnings fails and nothing else does.

Two things I havent checked: the right replacement for the Availability line in website/docs/externalwarnings.md, which already says "Premake 5.0.0-alpha1 or later for Visual Studio 2019+" despite gcc support, and whether clang should emit an explicit -Wno-system-headers for externalwarnings "Off". gcc doesn't, so I've left it alone.

This slipped in when externalwarnings was added to gcc in #1754 (065b3acb, merged 2022-01-04). That PR did touch src/tools/clang.lua, but only to rename sysdirs to extdirs. The mapping lives in three places rather than one: gcc declares it, clang keeps a hand-written copy of gcc's table rather than merging into it, and emcc deep-copies clang. A new key in gcc reaches none of them by itself, and an unmapped option just becomes a no-op, so nothing goes red.

Did you check all the boxes?

• Focus on a single fix or feature; remove any unrelated formatting or code changes
• Add unit tests showing fix or feature works; all tests pass
• Mention any related issues (put closes #XXXX in comment to auto-close issue when PR is merged) - none that I could find
• Follow our coding conventions
• Minimize the number of commits
• Align documentation to your changes - no docs change included