rules_pyrefly

Fixes #1 Summary add public and APIs support hint-based opt-in and suppression apply target-local preset, minimum severity, and per-error severity overrides document the precedence rules and exercise configurable behavior Testing @rickeylev, would you be willing to review this implementation?

I was adding pyrefly checking to rules_python in https://github.com/bazel-contrib/rules_python/pull/4009 and was pleasantly surprised at how easy it was! Thanks for that! I saw the there is some basic configurability using tags, but IMHO, that isn't as ideal. aspect_hints are better. Why aspect_hints instead of tags? Two main reasons: (1) aspect_hints is a configurable attribute, while tags is not. This means you can use select() and only trigger type checking if certain conditions are met. This also means that, if a user wanted to, they could use much more arbitrary and custom analysis-phase logic for deciding if something should be type checked. (2) aspect hints return provides, which means its an easy way to pass along configuration settings to pyrefly. I noticed that the pyrefly aspect has a variety of settings one can tune, for example. Encoding these as e.g. tags would be pretty tedious and brittle. A bonus of (2) is it creates a loose coupling between rules and type checkers. Something I've fretted over is how the py_library et al rules in rules_python would provide type checker integration without being specific to a particular type checker. Aspect hints makes for a pretty easy way to attach that information while keeping the coupling loose. It looked like the changes to support this were fairly simple (basically just also looking at the visited target's aspect_hints attribute). I'd send a PR, but that entails some paper work due to $dayJob, and I hate paperwork, so not sure when, or if that'll happen.