Allow applying static code-generation to the published package (i.e. `package.rs`)

Problem

When code-generation happens within build.rs or proc macros,

• Arbitrary code is being run on the developer's machine
• The generated code is harder to audit
• Code-generator needs to be built by all dependents when the result is the same

Proposed Solution

A package.rs that runs like build.rs during local development but the output gets captured on cargo publish and it, along with its dependencies, are dropped

If this were combined with a .crate differ on crates.io, it would be easy for dependents (or even package maintainers) to audit the results.

Notes

Past discussions

• Internals: "package.rs script to reduce build dependencies of published crates"
• zulip: "publish.rs"

Alternatives

• code-gen via snapshot testing which has more process overhead which is unappealing for high-churn code-gen

Cases not covered:

• Local development of a package that uses build.rs or a proc macro still has to deal with arbitrary code execution and not easily seeing what gets generated

Complications

• Knowing which dependencies can be stripped
• Inability for dependents to control versions of the code-generator to get the result of bug fixes, requiring a new release
• proc-macros that have tight coupling between the macro and the package that re-exports it
• Capturing proc-macro expansion
• Not subject to feature flags

Start by reading the linked Internals and Zulip discussions, then trace Cargo's existing build.rs and cargo publish flows. Define how package.rs output and dependencies would be captured or removed, including the listed proc-macro, feature-flag, and dependency-version complications; done means a settled design for the proposed behavior.