Split publish action into separate github job for better reporting

[SpecialBuilder32]

Splits the release build pipeline into separate jobs so we get better logging when one fails (i.e., expired tokens). Each distribution site has it's own job and can fail or be re-run independently of the others.

Publishing to gm4.co remains part of the build job, since it just pushes a commit to the release branch.

@misode please let me know if this looks correctly idempotent to you? I think I've implemented it that way, so long as we're requesting a re-run within the 2 day artifact expiry window.

Also also, I don't know if this is best merged before of after 26.3. Maybe at the same time? Let me know if I should redirect this from master to update-26.3

[misode]

I think it would be better if the build step uploaded the datapack zips to the github artifact together with the beet cache manifest. Instead of the publish steps pulling the zips from the release branch.

[SpecialBuilder32]

Alright @misode I think I've addressed the changes we discussed

[misode]

I'm still wondering why we are using beet for the publishing and summarizing stages. I don't think it actually helps with anything, instead we need all this hacky state passing (things like currently_publishing and gh_action_failed cache).

I imagine it would be easier to pass the built zips to an artifact and use those in a normal python script when publishing.