Add libclang-rt and sanitizer verification workflow

[scc-tw]

Closes #5

Summary

This PR ensures all Clang-based Docker images (versions 14–22) include the required compiler-rt (libclang-rt) runtime libraries and adds a GitHub Actions workflow that verifies key sanitizers (Address, Undefined, and Thread where available) for both Clang and GCC.

Background / Problem

Issue #5 reported that builds using -fsanitize=address with Clang 19 failed to link due to missing ASan runtime archives, with the linker even searching paths referring to an older LLVM version (e.g. clang/16). That indicates:

• The appropriate compiler-rt / libclang-rt runtime package for the active Clang version was not installed.
• And/or stale CMake or build cache entries still pointed at a previous Clang version’s runtime paths.

Without the correct runtime libraries (ASan, UBSan, TSan, etc.), sanitizer-enabled builds fail at link time, undermining CI reliability for projects depending on these images.

Changes in This PR

1. Docker Images (Clang 14–22):
   • Install the correct compiler-rt (libclang-rt) / sanitizer runtime packages for each version.
   • Ensure the selected clang++ (via update-alternatives or symlinks) matches the installed runtime set.
2. New Sanitizer Verification Workflow:
   • Matrix over (compiler: Clang/GCC) × (sanitizer: Address, Undefined, Thread where supported).
   • Builds and runs minimal test sources to confirm link + execution succeed.
   • Skips gracefully (with explanation) if a sanitizer is not supported on a given compiler/version.
3. Inline Documentation:
   • Added comments in Dockerfiles clarifying why libclang-rt is required and reminding maintainers to clean build caches after bumping compiler versions.

Rationale

Embedding the proper runtime libraries directly in each image and continuously validating them prevents late surprises in downstream CI pipelines. This “fail early” approach is especially important for projects that rely on sanitizers for memory safety and UB diagnostics.

Reproduction (Before Fix)

1. Use previous clang19 image.
2. Configure a project with -fsanitize=address and build with Clang 19.
3. Observe linker errors about missing libclang_rt.asan-*.a under an incorrect version path.

Validation (After Fix)

1. Build/pull the updated clang19 (or other) image.
2. Rebuild the same project with -fsanitize=address.
3. Link now succeeds; sanitizer runtime is found.
4. New workflow passes for Address/Undefined (and Thread where available).

Testing Performed

• Built representative images (e.g. 19, 20, 21) and verified presence of runtime archives in /usr/lib/llvm-<ver>/lib/clang/<ver>/lib/linux/.
• Ran sanitizer workflow:
  • ASan: build + run success.
  • UBSan: links and runs trivial UB-triggering sample.
  • TSan: included where supported; skipped otherwise with an explanatory message.
• Confirmed clang++ --version aligns with installed runtime path.

Maintenance Notes

• On adding a new Clang major version:
  • Install corresponding compiler-rt/libclang-rt package.
  • Extend sanitizer workflow matrix if needed.
• If expanding sanitizer coverage (e.g. MSan, LSan), may require additional image modifications (instrumented libs).

Possible Follow-ups (Not Included Here)

• Add MemorySanitizer (requires instrumented libc, more complex).
• Add richer test suite (multi TU, threads, UB variants).
• Document a compatibility matrix (image version → supported sanitizers).
• Publish artifacts or logs summarizing sanitizer coverage per run.

Related Issue

Closes #5 (missing ASan runtime libraries in Clang images).

Feedback welcome—especially on:

• Whether to split sanitizer tests into separate workflows (per compiler).
• Adding caching to speed up repeated matrix runs.

[mattkretz]

Thank you! Obviously my CI runs didn't include sanitizers (yet) :) Looks good to me. Now to figure out whether I can somehow test this PR without merging to main first. :-D