Rename SKIP and OPT_IN variables to remove any implied default

Migrated issue

Reported by: fjgarlin

Related to !214

Problem/Motivation

So far, we've used:

• SKIP_job_name to skip certain jobs. The name implies that the job is enabled by default and there are no exceptions to this rule
• OPT_IN_variant to run a set of jobs for a given variant. The name implies that the variant is disabled by default. The variants are: current, next/prev minor, next/prev major. So far, there is one exception, and this is current, where we have in the default templates OPT_IN_TEST_CURRENT: 1

The fact that the name of the variable carries a meaning into what the default value should be is limiting options. For example, in #3444789: Include upgrade status job for all contrib, we want to add a new job, but we don't want it enabled, or even the mentioned "current" variant is enabled by default, even if the variable name suggests that it should be off.

Proposed resolution

Simplify the names of the variables so they don't carry a meaning on whether they should be on or off by default.

• The SKIP_XXX variables would become _RUN_XXXX, for example _RUN_PHPSTAN, _RUN_CSPELL ...
• The OPT_IN_TEST_XXXX variables would become just _TEST_XXXX, for example _TEST_CURRENT, _TEST_NEXT_MAJOR ...

These names are neutral, and then we can decide whether we want them enabled by default or not.

I know that both the SKIP_ AND OPT_IN_ variables are heavily used from the early days, but it should be still easy to support the existing ones and translate into the new ones. For example, we know that SKIP_ESLINT: 1 would be the same as _RUN_ESLINT: 0 and the reverse too. The OPT_IN_TEST_ variables would not have any change in value, so OPT_IN_TEST_NEXT_MAJOR:1 just becomes _TEST_NEXT_MAJOR:1

So, the SKIP/OPT_IN variables could potentially be removed (or moved to the deprecated section), and then in the .pre job, we can turn on and off the switches based on whether we find these values set and warn the users about it. All the ".skip-...-rule" rules could easily be rewritten into the new format, and they probably don't even need a name change (the rule itself).

So, there are two tasks in this issue:
- Introduce the new simpler variables and rules that will give us a lot more flexibility for creating jobs or variants.
- Introduce a deprecation layer for the variables and rules so people start moving to the new versions. I think that this might be the most complex of the two tasks.

Let's use this issue to discuss thoughts, whether it makes sense or not (maybe it's a non-issue and we just make an exception for "upgrade status" job), whether it should be tackled in this version of provide a BC layer, or maybe just only a 2.x feature.

Happy to hear thoughts.

Related issue: Issue #3501054