Automate publishing of builds

[jonahgraham]

Today builds are published manually using these steps. We should automate this so, for example, a new tag gets published, similar to what cdt-gdb-vscode does for the marketplaces.

1. As a committer, ask @jonahgraham or EF helpdesk to be granted maintainer status on https://www.npmjs.com/package/cdt-gdb-adapter
2. Either run in a docker container, or install tools needed. See https://github.com/eclipse-cdt-cloud/cdt-gdb-adapter/blob/main/.github/workflows/build-push.yml or https://github.com/eclipse-cdt-cloud/cdt-gdb-adapter/tree/main/.devcontainer for guidance on required tools
3. Clone (or clean git clean -dfx) the cdt-gdb-adapter and ensure you are on HEAD of main.
4. Run yarn and yarn test to ensure everything builds correctly
5. Double-check that you have no uncommitted changes and your HEAD is the same as https://github.com/eclipse-cdt-cloud/cdt-gdb-adapter/tree/main
6. Run yarn publish. The current version will be something like 1.0.8-next, enter 1.0.8 as the new version (you may need username/password/token here depending on how you have configure security)
7. Push the HEAD to make a PR, this step is to get ECA approval. e.g. git push jonah HEAD:1.0.8 and then make a PR. Do not merge this PR in GitHub GUI because that will make the tag and commit not line up anymore. (see this pr for a past example)
8. Push HEAD and tag to origin git push origin v1.0.8 HEAD
9. Run yarn version to setup next development. The current version will be something like 1.0.8, enter 1.0.9-next as the new version.
10. Create and merge a PR with the commit for the version change. Don't bother pushing the tag, it has little value. (see this pr for a past example)
11. Create a PR on cdt-gdb-vscode updating it to the latest cdt-gdb-adapter, including in the changelog what changes the adapter update includes. (see this pr for a past example)

Step 9 is used because in the past we auto-published every commit with a next tag with this Jenkinsfile (when the project was part of eclipse-cdt). We could ditch that step if we don't plan to resume next tag publishing.

[jreineckearm]

Happy to have an initial look at this tomorrow. But cannot fully commit to taking over just yet.

Our friends from EclipseSource just recently added a publish workflow for the new UI components library and it looks fairly simple. See https://github.com/eclipse-cdt-cloud/.eclipsefdn/blob/62ab42dc46e1920bb7bf4caf5c70ef728e164cb9/otterdog/eclipse-cdt-cloud.jsonnet#L460 and https://github.com/eclipse-cdt-cloud/vscode-ui-components/blob/main/.github/workflows/publish.yml .

It triggers on pushing a tag like when creating a release from the Github web frontend. Just need to double-check something regarding the pull_request trigger now that I looked at it again.

I may take the shortcut of not automating commit of the new next version in a first iteration. Then we can see if the automated next publishes are heavily missed. But good to know that I can use such version for a test release. :-)

[jreineckearm]

Considered as done. @jonahgraham , please reopen if I missed something.