Struct-field deletion mutants ignore --re and --exclude-re

[P4suta]

Struct-field deletion mutants currently bypass the normal mutant-name filters.
Both CLI filters and their config equivalents are affected.

For example:

#[derive(Default)]
struct Settings {
    enabled: bool,
    count: usize,
}

fn settings() -> Settings {
    Settings {
        enabled: true,
        count: 1 + 2,
        ..Default::default()
    }
}

Running:

cargo mutants --Zmutate-file repro.rs --re "delete field enabled"

lists deletion mutants for both enabled and count. Conversely,
--exclude-re "delete field enabled" still lists the enabled mutant.

Struct-field deletion mutants should obey --re and --exclude-re like
the other mutant genres.

[jathorp]

The leaked mutants are executed and scored, not only listed: a regex-scoped run silently tests, and reports, mutants outside its scope.

Reproduced on 27.0.0 with a minimal crate whose only field-deletion site is Point { x: p.x + 1, ..Default::default() } in shifted:

• cargo mutants --re '^NOTHING_MATCHES_THIS$' tests delete field x from struct Point expression in shifted and reports it MISSED.
• --exclude-re '.*' still lists it.

--file does filter these mutants, but only helps when the wanted and unwanted mutants are in different files. On a real workspace we hit the case where they share one: selecting the other 46 mutants of a file by exact-name --re still pulled in its 5 field-deletion mutants, and no file-level selection can separate them. Until #634 lands, the only choices there are to run the whole file or not run it.

[P4suta]

Thanks. #634 filters these at discovery, so they are neither listed nor run; I checked both of your cases against current main.