Sync docs for `only:changes`, `rules:changes` and `rules:exists`

What does this MR do and why?

Various small changes are done for the CI docs for only:changes, rules:changes and rules:exists, to make them more consistent and comprehensive:

• In rules:exists, change doc link for Ruby's fnmatch from 2.7.0 to master, as was used in rules:changes and only:changes.
  • ❔ Was linking to a fixed version of the Ruby docs a deliberate choice? If so (and if that preference still exists), two things need to be done:
    1. We should do the opposite change, and convert the other instances of master links into versioned URLs
    2. We should confirm that the 2.7.0 version is still current (i.e. reflects the version of Ruby used by GitLab), or otherwise update it to the appropriate one.
  • Edit: this has been resolved: the preference is to keep the evergreen "master" link; see comment below.
• In rules:changes and only:changes, move the reference to Ruby's fnmatch to the "Additional details" section, as is done in rules:exists. This improves consistency and avoids giving the impression that fnmatch is only used for nested filename globs and not for e.g. directory or root file globs. It also uses the more detailed information (specifically, which flags are used in fnmatch) that was already present in rules:exists.
  • ❓ I'd like confirmation that these flags are indeed used in all globs; it's possible that the fnmatch invocation differs between rules:exists and rules:changes/only:changes (in which case, the difference should be made explicit).
• In only:changes, sync the format to match the near-identical text from rules:changes.
  • ❓ I didn't add the information about file paths now being able to include variables. Does that only apply to rules:changes or is it true for only:changes as well?
• In all three, link "flags" to the Ruby documentation for the filename globbing constants.
  • ❔ in case a versioned link is preferred (see above), this link should be updated accordingly.
  • Edit: this has been resolved: the preference is to keep the evergreen "master" link; see comment below.

Screenshots or screen recordings

N/A

How to set up and validate locally

Preview the edited markdown file and confirm that the output in the relevant sections (rules:changes, rules:exists, only:changes) is appropriate.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.