Granularize skippy configs for future work

[ZacSweers]

This is a part one toward exposing granular skippy configurations per tool. Currently it's still implemented in the project computer the same as before and just merges them all together, but will continue that work in subsequent PRs.

One thing I'm curious for thoughts on in this PR is if this approach of having the AffectedProjectsComputer makes sense, or if it might be better to keep it implemented the same as before and run multiple computer runs in parallel instead (where each task corresponds to the tool it's computing for). Then at the end we could aggregate their computed affected projects files and merge them. I'm leaning toward the latter but keen for thoughts!

[valeraz]

Parallelized approach would be nice. Since this will be running at the start of every CI build, it'd be nice to squeeze whatever performance we can out of it.

[ZacSweers]

Ok I've taken a pass at extracting an intermediary SkippyRunner API that can run multiple configs and reuse the existing AffectedProjectComputer. This came through quite nicely as it keeps the core of skippy more or less unchanged, and just adds APIs for supporting

• Supporting multiple configs
• Supporting overlaying global config onto custom configs
• Computing them in parallel
• Merging their outputs (also in parallel)