Add Common Lisp and Rust other sieves; improve C sparse marking

[MrJ-am]

Series: base #1084, wheel #1085, other #1082.

This PR now forms the other part of a three-category C/Rust/Common Lisp comparison. It retains the original Common Lisp solution 3 kernel: SBCL native storage, AVX2 multi-composite masks, fresh allocation and explicit release on every pass. The wheel changes remain in a separate PR.

It also adds Rust solution 9 with dense/sparse marking and 32 KiB block traversal, conservatively tagged other, and improves the existing C solution 5 pattern-extension sieve with an eight-write sparse period kernel. Runtime stride decomposition transfers the idea from Lisp/Rust to C. The new Rust entry preserves solution 1's base-category behavior.

Four paired five-second samples on one logical CPU of an AMD EPYC 9V74, limit 1,000,000, gave these medians:

Entry	Passes/s
C 5 original, fixed parameters	16,757
C 5 sparse periods, same parameters	18,156
Rust 9	16,229
Lisp 3, original PR kernel	15,905

The C gain is 8.3% at identical fixed parameters, with improvement in all four paired rounds. Separate default-autotuning checks were inconclusive (only one of three paired wins); this is not a claim of an established default-mode speedup. Lisp block-size and sparse-unrolling changes were rejected for lack of a stable gain.

Commands, raw measurements and limits are included. C's independent full-flag check covers both extension algorithms, three block sizes and limits through 10M. Rust optimized/debug tests and Lisp full flags, memory guards, lifetimes and 10M counts pass. No external sieve or prior pass result is reused.

Dockerfiles are included but Docker was unavailable locally. Draft pending container/CI review. The READMEs credit original authors, explain algorithm tags and document development with ChatGPT/Codex.

[rbergen]

@MrJ-am I'm going to have to ask you to stop and regroup.

Please:

• Don't open draft PRs. Only open a PR on the project when what you want to contribute is ready to review.
• Open one PR per solution, per language. The merits for the changes to the solution or the addition of it should stand on itself, in the context of the language and the language's existing solution you're aiming to contribute to.
• Do not add other artifacts besides solution contents, like comparison tools or outcomes. The comparison approach and tooling has been established and stabilized in the context of this project a long time ago. If you do want to make a structural, project-wide contribution in this area (i.e., one that does not focus on a subset of solutions) you can start a discussion to discuss your suggestions.

Based on the first point, I will close this PR and the other two you've opened.