FEAT: add KnownBadSignatureScorer for EICAR / GTUBE / GTphish

[Abdelhadi Salmaoui (abdelhadi703)]

Add a known-bad signature scorer (EICAR / GTUBE / GTphish)

PyRIT had no scorer for the standard scanner test signatures, so there was no way to
check whether a target returns a string an antivirus (EICAR), anti-spam (GTUBE) or
anti-phishing (GTphish) scanner should have stopped. Garak covers this with
av_spam_scanning; this adds the PyRIT-side detection.

What I changed:

• added KnownBadSignatureScorer in pyrit/score/true_false/regex/, built on the
  existing RegexScorer with the three signatures as default patterns
• exported it from pyrit.score and pyrit.score.true_false.regex
• added tests/unit/score/regex/test_known_bad_signature_scorer.py

One detail worth flagging: the signatures are the real EICAR/GTUBE/GTphish strings, and
a contiguous literal in a source file trips real-time AV on developer machines and CI
checkouts (the file gets quarantined before it's read). I assemble them from fragments
so the on-disk file stays inert while the runtime value is byte-for-byte the real
signature.

Testing: pytest tests/unit/score/regex/test_known_bad_signature_scorer.py — 10 passed.

Refs #511

[Abdelhadi Salmaoui (abdelhadi703)]

Both points addressed in 3b9656e.

The docs entry is in doc/code/scoring/1_true_false_scorers.py with its .ipynb kept in sync — that commit landed just before your review, so the CI failure it describes should already be resolved on the current head.

On the True semantics: agreed, and the wording is fixed. The docstring and the notebook entry now say the scorer reports literal marker presence, and explicitly note that a scanner can detect a marker and still deliver the message (your Cisco GTphish example) and that a target may have no scanner in front of it at all. The guidance is to read a hit against the policy the target is expected to enforce. Only comments and docs changed — matching behaviour is untouched.