[mypyc] Recompile dependents when a class's native_class or @trait changes

[rheard]

Fixes mypyc/mypyc#1232.

With separate compilation, adding @mypyc_attr(native_class=False) to a class between builds, or removing it, didn't recompile the modules that use the class if its module already imported mypyc_attr. Mypy doesn't record the decorator, so the module's interface hash didn't change. The stale modules then failed to compile against the class's new export table ('CPyDef_a___C': is not a member of 'export_table_a'). @trait had the same problem, and there the result was a segfault: the trait's module looked for a trait vtable that the stale subclasses didn't have.

This is the follow-up mentioned in #22128, using the same approach. MypycPlugin.report_config_data now returns (name, is_ext_class, is_trait, is_decorated) for each class in the module, in place of the list of decorated class names that #22128 added, and mypy includes the plugin config data in the interface hash. When the cache is written, these come from the tree, using the same is_extension_class, is_trait and is_decorated_class calls as build_type_map. When the cache is checked, the module hasn't been parsed yet, so they come from the cached IR.

The new tests turn each decorator on and off. A step in the middle changes only native.py and checks that other, which then has a non-native class or a trait, stays fresh, so a mismatch between the write and check paths would show up.

Other mypyc_attr flags that affect subclasses in other modules, such as serializable, have the same gap. I left them out since they'd mean repeating how prepare_class_def derives them, but I can add them here if you'd like.

[JukkaL]

Thanks for the fix!