Simple YAML-backed modules and single-file script modules, second iteration

[lihaoyi]

Different implementation of #5836, that uses code-generation to treat build/package.mill.yaml files as normal build/package.mill modules, rather than as external modules.

Advantages:

1. This allows use of normal trait modules without needing to package them up into special classes, so it can be applied much more generally to dozens of traits available in the Mill libraries
2. This allows multiple inheritance, e.g. extends: [mill.javalib.JavaModule, mill.javalib.PublishModule]
3. Modules defined in build/package.mill.yaml can interop much more cleanly with build/package.mill files, including type-safe references in either direction
4. We can handle things like requiring abstract methods to be defined in the YAML, since the YAML keys get code-gened into method implementations

Disadvantages:

1. Generated code can slow down compiles, whereas previous reflective instantiation was basically instant
2. Compile errors in generated code may be confusing to the user, since they didn't write the generated code themselves
3. Script files will still need to be instantiated reflectively from classes, as the ad-hoc nature of scripts means they may live in arbitrary files that are only discovered pretty late (e.g in the middle of execution of a show command that resolves things) that cannot be easily discovered during Mill's walkBuildFiles step
4. Script files cannot use test frameworks for now, though they can be tested via normal downstream scripts with main methods. This could be added in future