Feature: Rename OutcomePositive/Negative to something more aligned with the security implication of a probe finding

[pnacht]

Is your feature request related to a problem? Please describe.
OutcomePositive/Negative are big words for "yes" and "no". There have been various places/discussions requiring added logic to handle the fact that "yes" for one probe means it is safe, but for another probe it means it's dangerous (most recently, #3816 (comment)).

Describe the solution you'd like
Replace OutcomePositive/Negative (i.e. "yes"/"no") with "safe"/"unsafe": OutcomeSafe/Unsafe, OutcomeGood/Bad, etc.

I believe this will be more immediately legible: "ah, I don't even know what this probe is looking for, but apparently the project is safe from it!"

It may also simplify evaluation logic, since we don't need to special-case probes where Positive is a bad thing: OutcomeGood will always increase a project's score, OutcomeBad will always decrease it.

Describe alternatives you've considered
Probes could be renamed so that OutcomePositive always means it's safe. But this can lead to "negative" probe names (doesNotDoX), which doesn't follow the general coding principle that "variables" should be in the affirmative.

[spencerschrock]

See also: #3654

[spencerschrock]

OutcomePositive/Negative are big words for "yes" and "no".
It may also simplify evaluation logic, since we don't need to special-case probes where Positive is a bad thing: OutcomeGood will always increase a project's score, OutcomeBad will always decrease it.

Some of the maintainers synced offline and Positive/Negative were intended to be used in the manner you describe using Good/Bad. One downside is Positive / Negative have the unintentional confusion with "yes"/"no" that you mention.

I believe this will be more immediately legible: "ah, I don't even know what this probe is looking for, but apparently the project is safe from it!"

Part of the appeal of structured results is letting the consumer dictate their policy, so declaring certain behavior as safe or unsafe forces our policy on others to some extent. For clearly dangerous things (e.g. script injection), I doubt there will be disagreements. For more opinionated heuristics (commit activity, pinned dependencies, etc), we'd like to avoid imposing our bias.

So we're just going to avoid judgement and stay factual with True/False as a more clear yes/no. Which will let us avoid the weird names /added logic you referred to:

• notArchived -> archived
• freeOfBinaryArtifacts -> hasBinaryArtifacts