test: add valgrind memcheck/helgrind soak of the running module

[fzipi]

Stacks on #92 (Docker test environment) -- this branch is based on test/docker-build-environment, so the diff here is just the commit below until #92 merges.

Summary

• Add tools/soak.sh, adapted from coraza-nginx's tools/soak.sh: drives a real httpd (with the connector loaded) under valgrind memcheck or helgrind with concurrent benign and attack-shaped traffic for a fixed duration
• Unlike the nginx version, this soak also periodically issues a graceful restart (SIGUSR1) against the running master while traffic is in flight -- that's the exact operation issue apache graceful restart + Apache connector + rules = memory leak #82 reports leaking memory on, so the soak directly exercises it rather than just idling
• Add Dockerfile.fuzz, kept separate from the main Dockerfile per review feedback: it layers valgrind + curl on top of the already-built modsec3-apache-test image (docker build -t modsec3-apache-test . then docker build -f Dockerfile.fuzz -t modsec3-soak .) instead of duplicating the build
• Add .github/workflows/soak.yml: manual (workflow_dispatch) + weekly scheduled only, not on every PR -- a valgrind soak runs 10-50x slower than native, and see below, this connector currently has open leaks the soak is expected to (correctly) fail on
• Add tools/valgrind.suppress, a starter suppressions file with instructions for adding entries once confirmed genuine (APR pools free everything at pool-destruction time, so "still reachable" is expected noise; only "definitely lost" and tool error counts fail the soak)

What the soak already found

Running it locally (USE_VALGRIND=1) reproduces issue #82: every graceful restart leaks a rules_set --

5,549 (1,640 direct, 3,909 indirect) bytes in 1 blocks are definitely lost
   at operator new(unsigned long)
   by msc_create_rules_set (rules_set.cc:278)
   by msc_hook_create_config_directory
   by ap_single_module_configure
   ...

one such block per SIGUSR1, confirming the root cause is a rules_set never freed when the module re-reads its config on restart.

It also found a second, separate leak: an unbounded per-request leak in modsecurity::Transaction::intervention() (transaction.cc:1382) -- the intervention log message is strdup'd and never freed, growing with every blocked request (200KB+ per batch in a short run).

The helgrind soak runs clean on the connector's own code; its two findings (pthread_mutex_destroy at exit in libp11-kit, and a scoreboard write race in httpd core's update_child_status_internal) are pre-existing httpd-core/runtime noise, not this module.

I have not fixed either leak in this PR -- it's scoped to adding the tooling that surfaces them. Happy to open a follow-up for the fixes if wanted.

Test plan

• docker build -t modsec3-apache-test . then docker build -f Dockerfile.fuzz -t modsec3-soak .
• Plain run (no valgrind) passes cleanly, including a graceful restart mid-soak
• USE_VALGRIND=1 run correctly fails and reports the two leaks above with full stack traces
• USE_HELGRIND=1 run correctly completes and reports only pre-existing httpd-core/runtime noise
• shellcheck/shfmt clean on tools/soak.sh; actionlint/zizmor clean on the new workflow