Rule-generation support code

[lilatomic]

There are now several systems which generate rules. These rule-generators themselves have several common tasks. We have the opportunity to solve them in a consistent way.

Simple utils:

• parameter validation: many rule-generators take classes as arguments and expect these classes to have certain fields. However, the class may not actually have these fields. We can provide a standard way of validating these and reporting errors in a way that is friendly and usable for plugin developers. A simple way would be to use runtime_checkable protocols, or we could do more introspection. Pants already does similar filtering logic, there might be something to leverage there. We could also decide whether mixins or class decorators would be a good way of doing this.
• including upstream rules: rule-generators may need to pull in upstream rules. For example, the tool-based lockfile rules need the rest of the lockfile rules to function. This isn't hard, but is repeated. We should pick an idiom to just do that, especially there are a few different generators provided.
• test helpers: I found that since generated classes and rules are defined within the scope of their function, I couldn't actually reference them in tests (eg in the target of a queryrule). I worked up something to fish them out of all the rules I was registering, but we should have better helpers for this.

More complicated:

• rule uniqueness: A rule generator must return values that are equal by identity when provided with the same arguments. This prevents duplicate rules from being inserted into the rule graph. This situation came up for me exporting the same python tool under different plugins (eg radon has multiple subcommands). This can be as simple as slapping an @cache annotation on the generator function. It would be nice to have something more semantically meaningful (even if it is only rule_generator = functools.cache)
• better (unique) class names: the class name for generated classes is generally bad, because they exist as objects in the husk of a function. It would be great to have some mechanism to rename these to have some relation to their inputs.

I think I have a path forward on the simple utils. I think the only unknown for a v1 on those is where to put them. The more complicated ones could use some discussion. I'm not sure if it'd be good to just have an increasingly large bag of helpers, and I think it might be better to work up to having a RuleGenerator parent class which can provide some of this machinery (possibly automatically)

[lilatomic]

"including upstream rules" might not be necessary. The case I considered was lockfile rules for python tools, where every tool registered *lockfile.rules() . I included that in the rule generators because of that. But it turns out these were already registered as part of the python backend! so that might be the correct strategy here