Add new GitHub Action workflows to support WordPress Playground previews

[dkotter]

Description of the Change

As detailed in #41, this PR adds two new GitHub Action workflows:

1. Build the plugin and attach as an artifact
2. Add a link to WordPress Playground to the PR description, allowing for easier testing of individual PRs

The way this works is the following:

1. When a PR is opened, this will trigger the Pull Request Comments workflow
2. This workflow will then trigger the Build Plugin Zip workflow. This workflow builds the plugin and uploads it as an artifact to the PR
3. If this succeeds, the Pull Request Comments workflow will continue.
4. It first checks the contents of the PR description to see if a preview link already exists. If it does, the process stops. If it doesn't, it then continues
5. We then build up the blueprint data we need and add that to the WordPress Playground URL. This is then added to the PR description
6. In theory, when this link is clicked, WordPress Playground has code in place that will download the artifact and install that. This only works for repos in the WordPress organization, so this part hasn't been tested yet

Closes #41

Note

This PR contains .gitignore, composer.json, composer.lock, package.json and package-lock.json files that were copied over from #38, since that PR isn't merged yet. A few minor changes were made to package.json to support the build process but everything else matches that PR

How to test the Change

I was hoping the workflow would run properly on this PR but I think do to this being opened from a fork, it doesn't work.

All of this has been tested on my forked repo, though as noted there in the final step, the Playground link doesn't work properly as my repo isn't within a supported organization. But if desired, can see how things worked there:

• Successful run that added the comment
• Successful run that didn't add a comment because it already existed
• PR that had the comment added

Not sure there's a better way to test without merging this in :(

[dkotter]

Adding these two scripts and installing @wordpress/scripts are the only changes here from what is currently in #38, just as an FYI for reviewers

[dkotter]

Also worth noting we don't have anything to build yet so the actual build script here will need to be updated once we have something to build (like JS or CSS files)

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: dkotter <dkotter@git.wordpress.org>
Co-authored-by: jeffpaul <jeffpaul@git.wordpress.org>
Co-authored-by: paaljoachim <paaljoachim@git.wordpress.org>
Co-authored-by: adamziel <zieladam@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[dkotter]

GitHub supports a few options for calling a reusable workflow:

1. {owner}/{repo}/.github/workflows/{filename}@{ref}
2. ./.github/workflows/{filename}

I've gone with the second option here but can update it to the first if we think that's better. The one benefit there is we can specify a specific commit hash, similar to how we call 3rd party workflows, if we're concerned with the security of that workflow.

Because this workflow lives in the same repo, didn't seem like we needed to go that far but it's an easy update if desired:
WordPress/ai/.github/workflows/build-plugin-zip.yml@{commit SHA}

[jeffpaul]

Some questions and suggestions, but nothing that's truly blocking to merge this in and we can iterate as we go

[jeffpaul]

@dkotter I'll defer to you on merge order here between this and #38 to minimize conflicts

[jeffpaul]

#38 has been merged now, need to resolve conflicts here and then merge