Add GitHub workflow to update the Browserslist database

[igorschoester]

Context

Inspired by the State of the Code from @diedexx
But then a tryout with a smaller scope: updating the Browserslist database via a GitHub workflow/action

Summary

This PR can be summarized in the following changelog entry:

• Introduces a GitHub workflow, that can be manually triggered, to create a PR to update the Browserslist or caniuse database.

Relevant technical choices:

Using browserslist-update-action to:

• create the branch
• run npx update-browserslist-db@latest to update (see update-db)
• add files and commit
• create a PR

Test instructions

Test instructions for the acceptance test before the PR gets merged

This PR can be acceptance tested by following these steps:

AFAIK we cannot test this on this repository without merging it first.
I did test this myself by:

• creating a new (private) repository on my account
• check Allow GitHub Actions to create and approve pull requests in the repo settings > actions
  • this is needed for the workflow to be able to create a PR
• yarn init
• add dev deps as per a test fixture, including yarn.lock: https://github.com/browserslist/update-db/tree/main/test/fixtures/update-yarn
  • this is needed for the update-db to be able to have an update
• copy-pasting the workflow in there
• this I forgot, but you could create a label called changelog: non-user-facing
  • to test if that gets added to the PR
• run the workflow
  
• see that a PR is created
• the PR text should be similar to Updated caniuse-lite database for browserslist #20658

After merging we should ensure:

• the workflow indeed also works here
• the created PR should not trigger a changelog needed event on Slack 😅
• maybe switch to cron, as it will try to reuse the same branch; from their example (every 1st and 15th of the month @ 2 in the night):

on:
  schedule:
    - cron: '0 2 1,15 * *'

Relevant test scenarios

• Changes should be tested with the browser console open
• Changes should be tested on different posts/pages/taxonomies/custom post types/custom taxonomies
• Changes should be tested on different editors (Default Block/Gutenberg/Classic/Elementor/other)
• Changes should be tested on different browsers
• Changes should be tested on multisite

Test instructions for QA when the code is in the RC

• QA should use the same steps as above.

QA can test this PR by following these steps:

• N/A

Impact check

This PR affects the following parts of the plugin, which may require extra testing:

UI changes

• This PR changes the UI in the plugin. I have added the 'UI change' label to this PR.

Other environments

• This PR also affects Shopify. I have added a changelog entry starting with [shopify-seo], added test instructions for Shopify and attached the Shopify label to this PR.

Documentation

• I have written documentation for this change. For example, comments in the Relevant technical choices, comments in the code, documentation on Confluence / shared Google Drive / Yoast developer portal, or other.

Quality assurance

• I have tested this code to the best of my abilities.
• During testing, I had activated all plugins that Yoast SEO provides integrations for.
• I have added unit tests to verify the code works as intended.
• If any part of the code is behind a feature flag, my test instructions also cover cases where the feature flag is switched off.
• I have written this PR in accordance with my team's definition of done.
• I have checked that the base branch is correctly set.

Innovation

• No innovation project is applicable for this PR.
• This PR falls under an innovation project. I have attached the innovation label.
• I have added my hours to the WBSO document.

Fixes #