reporting: update report aggregation funcs

[leondz]

This PR allows a variety of group-level aggregations in reporting

There are risks in using aggregated garak results, e.g. taking means of all probes in one category. Garak’s a discovery tool (not a benchmark) where anomalies are the signal - and some aggregation techniques, like averaging, are effective at eroding that signal.

Two vignettes of how averaging makes garak results unusable:

1. Model A scores pretty well at all probes in a category. Model B scores the same but fails hard on one probe. Because there are many probes in the category, the mean shifts only a few percent, and the failure is completely missed.
2. A probe category has a high-risk and a low-risk pro​​be. Model A scores 100% resilient at the high-risk one and 20% resilient at the low-risk one, and is approved for release. It gets a mean of 60%. Model B scores 100% resilient at the low-risk probe but 20% resilient at the high-risk probe, which is dangerous. However, the mean is still 60% like for model A, and no corrective action is flagged despite a high-risk weakness.

The proposed change is to:

• Add more aggregation options - e.g. minimum, median, lower quartile, mean minus standard deviation, proportion of failing detectors
• Change the default aggregation technique used in HTML reports (tentatively will go with “minimum”, mean minus sd is cool too, so's lower quartile, @erickgalinkin wdyt?)
  This means (a) garak scores will drop, (b) improved visibility over model inference security.

Additional changes:

• report HTML has been cleared up, with descriptions moved to hover text, and duplicate content removed
• always.Random detector that gives random scores in 0..1

• Tier-based changes are pending merge of update: add probe tiers #1151
• Hardcoded cutoff is present pending merge of script: qualitative review output #1144
• This continues to access _config; report_digest needs to be able to run standalone, and running it multithreaded is not intended to be supported

Verification

• Try to generate test results w/ e.g. python -m garak -m test -p encoding,xss,ansiescape -d always.Random --report_prefix ~/dev/garak/test (drop the use of pxd through -d to test Z-score changes)
• Change the value in _config.reporting.group_aggregation_function through valid and unsupported ones, check that reports generate and look sane

[mrowebot]

Is 40 a hard probe score limit? If so, perhaps have:

Suggested change

	len([p for p in probe_scores if p > 40]) / len(probe_scores)
	DEFAULT_PROBE_SCORE_PASSING_THRESHOLD = 40
	len([p for p in probe_scores if p > DEFAULT_PROBE_SCORE_PASSING_THRESHOLD]) / len(probe_scores)

?

[leondz]

it is - PR #1144 makes this a constant and usage here will be updated once that lands

[mrowebot]

Is instantiation with None necessary here given that your default case is handled below?

[leondz]

Valid point. I think it's good if things explode in test (eg. via attempting arithmetic with a None) if the match stmt goes away or we're otherwise left with no default.

[erickgalinkin]

Looks reasonable to me! @mrowebot's comments are valid, but not necessarily worth holding up the merge.
We can make this more fully-fledged and merge it with the more rigorous approach I took in a private branch as we move forward.