🚀 Feature: Add a concept of "unsafe" fixes / suggestions

[JoshuaKGoldberg]

Feature Request Checklist

• I have pulled the latest main branch of the repository.
• I have searched for related issues and found none that matched my issue.

Overview

Linters these days seem to be split on how to handle fixes that change runtime behavior:

• A separate "suggestions" API, e.g. https://eslint.org/docs/latest/extend/custom-rules#providing-suggestions
• Marking fixes individually as "safe" or "unsafe", e.g. https://biomejs.dev/linter/#unsafe-fixes

I'm definitely leaning towards the latter to avoid having such separate concepts. There might actually be >=4 levels of fix safety?

1. Cosmetic: does not change any runtime code, e.g. changing Array<T> to T[]
2. Runtime-safe: changes runtime code in a way we're 99.9...% sure is safe, e.g. changing object && object.a to object?.a
3. Runtime-suggested: probably safe but needs manual confirmation, e.g. removing an unnecessary async from a function
4. Opt-in: one of several options, e.g. adding a word to a spell checker dictionary

...but is that actually a cross-matrix? Should there be a delineation between "probably safe" (2.) between logical and stylistic rules, for example?

Design investigation work very much needed.

Additional Info

Blocked on #53: having a base concept of fixes. ✅

See also discussion in eslint/rfcs#134 around per-message(Id) configuration.

❤️‍🔥

[JoshuaKGoldberg]

After thinking about this a bit, I don't think it makes sense to bake in such granular definitions for suggestion "levels" so early. I'm going to go ahead with just a suggestions?: Suggestion[] array akin to ESLint's.