automatically publish builds for new snapshots

[ix0rai]

it should be technically possible to auto-publish builds for new Minecraft versions, as Quilt does with hashed mappings. this would allow using parchment for snapshot development as well as relieve some maintenance burden, along with opening up new possibilities for parchment to collaborate with other mapping sets.

[sciwhiz12]

It is technically possible, but would require a good amount of work to implement.

• The mappings can be migrated using ParchmentJAM, which is integrated into Compass as documented in https://github.com/ParchmentMC/Parchment/blob/2ff3f6cc3363c8f849f7d4a3f02e1e51d0cd3421/docs/mgirating_data.md. (Dammit, only now I notice the typo in the file name.)

  However, the migration is somewhat lossy, particularly for lambda methods (lambda$-prefixed methods). An element of human intervention will still be needed to check over the generated outputs and restore any mappings that might've been removed accidentally. Improving JAMMER to work better with lambdas might be possible, but it'll be a sizable chunk of work in and of itself.

• We'd have to define how to handle snapshots in our versioning, both for the branches and the exports.

  Currently, we name our branches versions/<##>.<##>.x, and publish our exports under org.parchmentmc.data:parchment-<##>.<##>.<##>:<DD>.<MM>.<YYYY>. If need be, we can rename all our version branches to a new scheme, but the published artifacts in the Maven repository must stay where they are as clients expect them to be there.

• We possibly want to decide what automation platform will be responsible for the automated migration in the long run: TeamCity (which is our current CI, at https://buildsystem.ldtteam.com, courtesy of @marchermans and @ldtteam), or GitHub Actions.

  The reason I bring this up is because we currently have all our automation on TeamCity: PR building, project publishing, Blackstone generation, website generation, and so on. While this is currently fine (aside from a few hiccups here and there), it may be worth investigating GitHub Actions as a potential alternative.

  One major reason I can pick out is that, because Actions workflows are defined in the same repository as the code, it is much easier for others to fork ParchmentMC's repositories and continue our work, should something happen to us, the ParchmentMC team.

  However, I only bring this up as a potential point of discussion -- I am not committing to changing to GitHub Actions until we investigate and decide. For now though, we can assume to use TeamCity.

• We need to manage how PRs are to be handled, in light of the potential of snapshot mappings. (This will be more relevant once the branch scheme is decided on.) This will involve the @ParchmentMC/mapping-standards team, as the stewards of our contribution process.

• Once all of the above are considered and acted upon, then someone (possibly/likely me) will need to implement them, which might take time depending on how much needs to be done to prepare everything (and the available time to do those things).

That's a non-exhaustive overview of what needs to be handled for this.