Add sanitizers

[VukPavicRTRK]

This PR adds sanitizer support and CI integration for ASan, UBSan, LSan, and TSan.

Changes

• Added centralized sanitizer configuration under quality/sanitizer/
• Added GitHub Actions workflows for sanitizer test runs
• Imported sanitizer configs into .bazelrc
• Added cc_test_with_common_opts wrapper to simplify test setup
• Updated existing tests to use the new wrapper
• Added suppression files and runtime wrapper for known sanitizer false positives

Sanitizer builds now run automatically for PRs, merge groups, and pushes to main.

Closes #50.

[github-actions]

License Check Results

🚀 The license check job ran with the Bazel command:

bazel run --lockfile_mode=error //:license-check

Status: ⚠️ Needs Review

Click to expand output

[License Check Output]
Extracting Bazel installation...
Starting local Bazel server (8.4.2) and connecting to it...
INFO: Invocation ID: 07300a5b-c7d6-458c-a333-dafb8caffe9d
Computing main repo mapping: 
Computing main repo mapping: 
Loading: 
Loading: 0 packages loaded
Loading: 0 packages loaded
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Loading: 0 packages loaded
    currently loading: 
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)
Analyzing: target //:license-check (1 packages loaded, 0 targets configured)

Analyzing: target //:license-check (28 packages loaded, 10 targets configured)

Analyzing: target //:license-check (84 packages loaded, 10 targets configured)

Analyzing: target //:license-check (90 packages loaded, 20 targets configured)

Analyzing: target //:license-check (144 packages loaded, 3703 targets configured)

Analyzing: target //:license-check (149 packages loaded, 5380 targets configured)

Analyzing: target //:license-check (154 packages loaded, 5429 targets configured)

Analyzing: target //:license-check (158 packages loaded, 8210 targets configured)

Analyzing: target //:license-check (161 packages loaded, 10106 targets configured)

Analyzing: target //:license-check (161 packages loaded, 10106 targets configured)

INFO: Analyzed target //:license-check (162 packages loaded, 10232 targets configured).
[14 / 16] [Prepa] JavaToolchainCompileBootClasspath external/rules_java+/toolchains/platformclasspath.jar
[15 / 16] Building license.check.license_check.jar (); 0s disk-cache, multiplex-worker
INFO: Found 1 target...
Target //:license.check.license_check up-to-date:
  bazel-bin/license.check.license_check
  bazel-bin/license.check.license_check.jar
INFO: Elapsed time: 22.895s, Critical Path: 2.55s
INFO: 16 processes: 12 internal, 3 processwrapper-sandbox, 1 worker.
INFO: Build completed successfully, 16 total actions
INFO: Running command line: bazel-bin/license.check.license_check ./formatted.txt <args omitted>
usage: org.eclipse.dash.licenses.cli.Main [-batch <int>] [-cd <url>]
       [-confidence <int>] [-ef <url>] [-excludeSources <sources>] [-help] [-lic
       <url>] [-project <shortname>] [-repo <url>] [-review] [-summary <file>]
       [-timeout <seconds>] [-token <token>]

[github-actions]

The created documentation from the pull request is available at: docu-html

[FScholPer]

be aware there is also going work in that direction in score_cpp_policies repo

[VukPavicRTRK]

be aware there is also going work in that direction in score_cpp_policies repo

Should lifecycle continue with the self-contained sanitizer implementation in this PR as a short-term unblocker, planning a later migration to the shared score_cpp_policies module once its sanitizer structure stabilizes or do we want to pivot now and integrate directly with the centralized sanitizer infrastructure despite the potential dependency and release-readiness risks?

[FScholPer]

My opinion: I would say we should bring in our thoughts into score_cpp_policies and not create silos. @NicolasFussberger @S-MOHAMD @pawelrutkaq any thoughts on this?

[NicolasFussberger]

My opinion: I would say we should bring in our thoughts into score_cpp_policies and not create silos. @NicolasFussberger @S-MOHAMD @pawelrutkaq any thoughts on this?

If we can bring in these changes into score_cpp_policies, I agree that this should be the preferred solution. I cannot judge how realistic this is.