Update the CI workflows to run on only schedulers relevant for the the change

[hodgesds]

Why

This will make everyone's lives a little better working on sched_ext by having faster CI signals.

What

Update the existing github workflow to aware of changes that it is running on. For example a change to scheds/rust/scx_bpfland should not trigger any of the schedulers written in C (scheds/c) nor any other rust schedulers (ex: scheds/rust/scx_lavd). Changes to common/build code should still test all schedulers (ex: meson-scripts).

[arighi]

Sounds like a really nice thing to me, I was actually planning to look at this at some point. I should be able to find some time this week.

[likewhatevs]

I think GH-632 meets idk the intent of this well.

It splits out test jobs etc. but always runs them.

GH actions don't (to the best of my knowledge) have a "not ran state" that is able to accept non-predefined data.

That's not to say one couldn't hack it in (nor would that be particularly tricky), but like, that paired with the inability to compose steps really well (actions afaik can only run shell cmds) would mean that conditionally running jobs like this would probably need both:
a) some kind of artifact or cache passing between steps to communicate what should be ran.
b) having less helpful pass/fail states (i.e. pass == not ran).
c) an uncomfortable amount of boilerplate (which I'd probably add some script to write, so that's less of an issue).

(b) is the best reason to just run all at once (and they're fast for now).

Imo, how mitosis is handled covers how to deal w/ jobs that continually fail (turn them off by removing them from the list in meson and the lists in the ci config), so maybe that PR meets the need of this issue.