Add configurable line-based mutation filter

[lexendo]

Closes #585

This PR introduces a new filter (line_filter.py, exposed as cr-filter-lines) that allows running Cosmic Ray only on specific lines defined in the config.

When working on a small part of the codebase (e.g. refactoring a function), it is useful to run mutation testing only on relevant lines instead of the whole module. This filter enables that in a simple and explicit way.

---

What was added

• New filter: line_filter.py
• CLI tool: cr-filter-lines
• Configurable line ranges per file
• Basic smoke tests

---

Configuration:

Supported formats in cr config file:

[cosmic-ray.filters.line-filter.lines]
"math.py" = "1-4"
"util.py" = ["4", "10-22"]

or

[cosmic-ray.filters.line-filter]
lines = { "my_math.py" = "2", "my_utils.py" = "3-4" }

Notes:

• Values can be "5", "10-20" or a list
• Multiple files supported
• Only mutations overlapping configured lines are executed
• Others are marked as SKIPPED

Usage:

1. Configure the lines you want to mutate in the config file
2. Initialize a Cosmic Ray session (init)
3. Run the cr-filter-lines filter on the session
   cr-filter-lines cosmic-ray-sql.sqlite --config cosmic-ray-config.toml --verbosity INFO
4. Execute mutation testing as usual (exec)

Summary:

Adds a simple way to focus mutation testing on selected lines.

[abingham]

I like the concept of this filter. There are a few things I'd like you to look at, though.

First, I think there's a "configuration gap" in the current implementation. If my module-path is a single file like, e.g. mod.py, then I don't see how I'd do line-skipping in that file. One approach that might work is to not rely on module-path and just make users specify the full path to files. If we detect that they've specified a file outside of module-path we could issue a warning or error. But maybe there are better ideas; I'll leave it up to you to explore the space.

Second: if --config is not provided, won't we end up skipping everything? This seems like a misfeature to me. Should we just require --config? Or perhaps warn if/when all mutations are skipped?

Third: I'd like more tests, esp. at least one that will run in CI. These don't need to be e2e tests, but I'd like something that verifies that the core logic works. Could you create a WorkDB, populate it with some WorkItems, and then verify that the functions in your filter correctly skip items?

Again, I think this is a great idea, and I'd love to see it get to a state where I can merge it.

[lexendo]

Thanks, for the feedback, I agree.

For the single-file module-path gap, I updated the path resolution logic so the filter now distinguishes between directory-style and single-file module-path values. In the single-file case, it accepts either the full file path or just the basename, and if a different file is configured it now logs a warning and ignores that entry instead of failing.

For --config, I made it required so we do not end up silently skipping everything when no config is provided.

I also added more tests. Besides the smoke tests, I updated them to pass --config, and I added core logic tests that use a fake WorkDB populated with WorkItems to verify skipping behavior for configured ranges, multiple files/ranges, overlap checks, and path resolution/parsing behavior. So there is now CI-friendly coverage for the main filter logic as well.

I pushed the changes.