ci: upload pre-built artifacts

[TomasArrachea]

Closes 0xMiden/midenup#200

Superseeds #2859.

This PR adds:

• generate-packages binary that extracts the pre-built protocol and standards packages from ProtocolLib/StandardsLib and writes them to target/packages. This was changed from the cargo -Zscript approach so the dependencies are resolved from the lockfile. The crate is excluded from the no-std build and clippy targets since it requires std.
• An upload-artifacts job in the workspace-publish workflow that attests and uploads protocol.masp and standards.masp to the GitHub release page so midenup can use them.

[TomasArrachea]

Actually, I think this can be improved to avoid having to add the generate-packages binary. Instead we can just cache the target when it's compiled by the CI, and have the upload-artifacts access the cache and load the .masp artifacts. They should be available since they are now generated at build time.

[PhilippGackstatter]

Actually, I think this can be improved to avoid having to add the generate-packages binary.

Agreed. The main question is probably whether we want the package to contain debug info or not, and this will depend on how the package is built before it is added to the cache. I guess the typical approach would be not to include debug info ("release mode"), but it might also be quite helpful to have a package with debug info available, so maybe it should be both?

[bitwalker]

Just one issue that I think can be resolved by moving responsibility for this into the respective build scripts, otherwise 👍

[bitwalker]

I'm concerned this could pick up previous build artifacts from the cache. Why not have the build script of the protocol/standards crates write the package output to $CARGO_MANIFEST_DIR/../target/$PROFILE/<package>.masp (you may need to adjust the the number of ../ segments based on the folder hierarchy of each crate).

Then you will always know that after building those crates, the .masp files under target/$PROFILE/ will be the exact ones you requested

[bitwalker]

Actually, I think this can be improved to avoid having to add the generate-packages binary.

Agreed. The main question is probably whether we want the package to contain debug info or not, and this will depend on how the package is built before it is added to the cache. I guess the typical approach would be not to include debug info ("release mode"), but it might also be quite helpful to have a package with debug info available, so maybe it should be both?

Packages should always include debug info when published - it can be stripped as-needed (though we aren't publishing packages on-chain, so it isn't clear to me that packages even need to be stripped, but AIUI the client does strip debug info from the MAST in versions of MAST that store debug info as part of the MAST - no longer the case starting in v0.25).

[PhilippGackstatter]

Btw. do we also plan to migrate miden-agglayer to miden-project and include that package in the uploaded artifacts as well? I assume we need to do this eventually (separate from this PR).