[WIP] feat: add dependency management automation (#1676).

[aorinevo]

Changes

• See Issue Dependency Management Automation #1676

[nknapp]

Thanks for this. It would be great to use semantic-release to do the actual release. It would simplify many things.

I think we should approach this in the following way:

1. Add the semantic-release config to the 4.x-branch, but not the github-action. For the time being, we can run npx semantic-release locally but we can still revert to the old way of using yo release if it does not work as expected.
2. Migrate travis and appveyor to github actions.
3. Once we've confirmed that npx semantic-release covers the current release workflow and all targets, we can move it into the action.

Here are my pain points:

• I am not sure that I know everything that yo release does in the background. I also don't know yet, what tasks/scripts npx semantic-release actually executes in order to build the project. But I am pretty sure that those are not the same at the moment. I want to test this manually before getting into automation.
• My npm and gem accounts have MFA activated, which means that I have to enter an one-time-password when I publish packages. This is for a good reason: To prevent that something like the eslint-scope issue happens to Handlebars or other packages that I publish on npm. If we fully automate releases, I would like to maintain that level of security. I think we first have to explore the possibilities here.

I think it is acceptable to type npx semantic-release in order to get a new release. And it's a major improvement compared to what we have to do right now.

[jaylinski]

It would be nice if we could do npm package provenance for verified builds:

https://github.blog/2023-04-19-introducing-npm-package-provenance/