Ability to opt-in pull requests/packages to run check in CI

[jeremyd2019]

In #20651, @filnet requested a way to run packages' check functions in a PR.

Potential ideas for accomplishing this:

1. Add a new workflow, with workflow_dispatch trigger, and have maintainers with access trigger manually. This doesn't really work very well, because it is not associated with a PR and needs manual intervention by maintainers
2. Use some property of the PR to decide whether or not to run checks. My ideas were either triggering on something in the pull request's head branch name (ie, contains _check or something like that), or the PR has a run-checks label, which would be cleaner, except it still requires manual intervention by maintainers who have rights to label PRs (you can set labels in an issue template but apparently not in a PR template).
3. @filnet suggested adding another list file and doing similar to ci-dont-install-list.txt to determine whether or not to run checks for a given package. I am concerned that that does not scale well if the list file gets long, and that not every PR for a package would necessarily want to run the checks. (See 714a25f)

I felt this was getting kind of off-topic for the PR in question, and wanted to expand the discussion to hopefully get a feel if there are other ideas, or if any of these ideas are preferred over others. I was kind of partial to triggering off of a PR label, but can't see a way to let unprivileged users use it (without also adding some bot-type thing that users can ask to do it)

[Biswa96]

4. Disable default check option in /etc/makepkg*.conf. Enable check option in individual PKGBUILD as needed.

Warning: This change would break every assumptions from ArchLinux (PKGBUILD), AlpineLinux (APKBUILD) etc. packaging system.

[MehdiChinoune]

@jannick0 suggested in #19545 to run check in contributors forks.

[filnet]

Do we want to run checks after merging in master ?
We can get check failures in master if some dependency has been updated between the check in the PR and the merge in master.

Solutions to that problem include:

1. not run check in master but then we risk publishing something broken
2. switch to fast forward only merge policy

[filnet]

I created a PR in my fork to test @jannick0's suggestion but CI is not running.
Is it possible to have CI running in a fork and, if yes, how does one set it up?

[filnet]

I managed to enable CI in my fork but now have two issues:

• CI runs twice: on push and on pull_request (see https://github.com/filnet/MINGW-packages/pull/2/checks)
• I can't set the expected CI_MAKEPKG_RUN_CHECK env variable to trigger the check

I declared it in <myfork>/MINGW-packages/settings/variables/actions.

But it does not seem to be visible to CI.
I added a step to CI to list all the environment variables and CI_MAKEPKG_RUN_CHECK is not listed.

@jannick0, do you remember how you set this variable ?