Add release workflow

[SillyFreak]

This adds a second GH Actions workflow that prepares a release of the package:

• the workflow runs on pushes to tags starting with v...
• the version number in typst.toml is checked to match the tag
• the package's docs are recreated and the package is bundled for universe (just doc, just package)
• a user-specified repo (should be a fork of https://github.com/typst/packages/) is checked out
• the package is added to it at the right path (packages/preview/<package>/<version>)
• the changes are committed and pushed to a new branch named <package>-<version>, using the name and email of the tagged commit

The result is that the so-created branch is ready for opening a PR against typst/packages. The workflow needs some configuration because it needs write access to the typst/packages fork (and needs to know what repo to use for that purpose); I documented that in the README, hopefully that's sufficient.

One thing I wasn't sure about is whether giving the token full write access is the best way to do this, or if there's maybe a PR or similar permission that could be used. I didn't want to try to open PRs directly against typst/packages, because I think that would necessarily circumvent that repo's PR template. Feedback on that or anything else would be appreciated.

[tingerrr]

Regarding the automatic PR, I think the way it works now (by simply creating a branch ready for making a PR) is actually fine. This way, the workflow avoids requiring a permission scope which is too wide for its use.

I generally open a PR to typst/pacakages, then to my own package, and only merge the latter once the former is merged. This way, if you look at the README of my package, the example version is never ahead of the Typst universe version. But that's probably the only upside for that. Maybe that's just a symptom of my lack of a release workflow, too.

[SillyFreak]

I generally agree with your review; it would be better if the template's features depend less on platform-dependent tools. I actually forgot about the Perl script buried in there; I thought this was at least just bash.

bash is horrible to read and write, but at least outside Windows it can be kind of assumed.

I'll need to have a look at utpm, although its approach seems to be different. I can imagine reimplementing the scripts in Rust so that they are not just obscure scripts within this template, are portable, free the template from documentation for them, etc. - but I also don't want to invest that energy right now as it already does what I want.

Personally, as this PR doesn't regress the portability of the scripts, I lean towards merging this PR and later replacing over not merging and waiting for the replacement, but I'm open to doing it differently (the impact of this template's state is probably small anyway rn)

[tingerrr]

I think merging in its current state is fine, all in all it's an improvement and portability can be of concern later.

[SillyFreak]

btw

I generally open a PR to typst/pacakages, then to my own package, and only merge the latter once the former is merged. This way, if you look at the README of my package, the example version is never ahead of the Typst universe version.

I think that should still be possible, it just requires that you tag a commit that is not yet merged into main with the release version, which is not typical I guess. If your merge strategy is fast-forward here, eventually it will look normal. Otherwise, you could probably tweak the workflow to trigger on you opening a PR with a specific title, label, or similar. Then you could tag the commit after it has actually been merged.