Plugin archive workflow

[Biont]

Please check if the PR fulfills these requirements

• The commit message follows our guidelines
• Tests for the changes have been added (for bug fixes/features)
• Docs have been added/updated (for bug fixes/features)

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
feature

What is the current behavior? (You can also link to an open issue here)
The products team is using multiple individual processes for plugin archive generation. There have been attempts to unify this, but the fact remains that these processes are maintained for each plugin separately.

What is the new behavior (if this is a feature change)?
The ability to share a unified workflow across multiple products would mean a substantial improvement in our workflows and maintenance efforts.

Please note that this is strictly an "build" workflow and not a "release" workflow and should not be confused with one. It is very common for us to create a my-plugin-JIRA-123.zip build off some feature branch in order to pass on an issue to QA. Given that this constitutes ~98/100 builds that we will be doing, you could go as far as to say that is the primary objective.

To implement it, I have tried to stay close to existing practices and using existing tools where possible

• Environment (PHP/JS) setup follows existing steps used in other workflows inside this repository
• Asset compilation & downloading of translations can be done via our respective composer plugins. For this the workflow checks if each of these packages is actually used by the project and then executes the respective command.
• For the actual archive generation, I had to pick a new solution and went with the wp dist-archive command for these reasons:
  • It has builtin support for an exclude list (like rsync --exclude-from) for reducing clutter from resulting archives
  • Despite not being bundled, it is an official tool of the "WP-CLI" ecosystem, built for this exact purpose. We hopefully won't need to find a replacement anytime soon

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
No

Other information:
Please feel invited and welcome to squash-merge this PR. Next time I will try to setup something I can more easily replicate with nectos/act, but for this instance, I just had to do a LOT of trial&error commits

[tyrann0us]

I'm sorry for the massive delay. I wanted to take time because there are quite some things that can be improved.

Apart from the line comments, please also update the documentation accordingly. Thanks!

[Biont]

@Chrico suggested replacing EXTRA_PHP_* by a simple PRE_SCRIPT - an input that just takes raw shell

[tyrann0us]

Thanks for incorporating the changes! LGTM.