chore: optimize CI by skipping unnecessary jobs

[nogeenhenk]

Summary

Skip expensive CI steps when irrelevant files change, without affecting required checks.

Approach

Instead of using paths filters at the workflow trigger level (which can leave required checks stuck in "pending"), this PR:

1. Always triggers workflows
2. Uses a cheap changes job to detect modified files
3. Jobs always run and report success
4. Heavy steps (Qt install, build, test) are skipped internally when not needed

This saves CI time while avoiding the "pending required check" issue.

Changes

Workflow	Heavy steps skipped when
ccpp.yml	no src, tests, Qt, localization, icons, docs changes
codeql.yml	no src, tests changes
linter.yml	no relevant code, yaml, markdown, scripts, etc. changes
publiccode.yml	no publiccode.yml changes
docs.yml	no src, tests, docs changes
release-installers.yml	no src, tests, Qt changes
reuse.yml	always runs full (repo-wide compliance)

merge_group

All workflows also trigger on merge_group to ensure full CI passes before merging.

Benefits

• Docs-only PRs complete instantly (heavy steps skipped)
• Required checks always report SUCCESS (never pending)
• No branch protection changes needed

[coveralls]

coverage: 18.447%. remained the same
when pulling 4450742 on chore/ci-path-filtering
into 2ffedf6 on main.

[annejan]

I think we can push this a bit further while also avoiding the “pending required check” edge case.

Instead of relying on paths at the workflow trigger level, we can keep workflows always running and gate the expensive jobs internally based on changed files. That way:

• required checks always report (no pending state)
• docs-only PRs still complete almost instantly
• we avoid burning CI resources unnecessarily

Issue #854 moves in a heavy direction while we are introducing a lightweight “changes” step and conditionally running the heavy jobs.

So the pattern would be:

• always trigger the workflow
• detect relevant changes early
• only run build/test jobs when needed
• otherwise exit fast with success

This gives us the same optimization goal, but without needing to adjust branch protection rules or risk blocking merges.