CI: [changeset_base] refined to merge-request pipeline files

What

Restricts [changeset_base] to CI YAML files relevant to merge-request pipelines ([before_merging], [merge_train]).

Why

Currently, MRs touching non merge-request pipelines (e.g. branch pipelines such as [master_branch] pipelines, or scheduled pipelines such as [schedule_extended_test] pipelines) trigger merge-train pipelines containing all conditional jobs.

This is unnecessary as it will not test the changes made by such MRs. To test them, you would need to run test pipelines for the modified pipelines (e.g. using [ci/run_pipeline]).

In order to reduce wall-time and CI costs, we restrict the changeset to merge-request pipeline files only. This is safe because jobs in non merge-request pipelines do not have changesets. (As you can see this MR does not modify pipelines other than [before_merging] of [merge_train] ones.)

How

• Simple change + make -C ci.

Manually testing the MR

• make -C ci check
• [before_merging] pipeline should be green: https://gitlab.com/tezos/tezos/-/pipelines/1918762044, duration 32m01s
• example of a [before_merging] pipeline for a MR that touches a non merge-request pipeline:
  • cf. https://gitlab.com/tezos/tezos/-/pipelines/1918769108 in !18637
  • duration: 9m51s vs 32m01s for this MR's before merging pipeline

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR