engine/generators: Add RecordGenerator abstraction

[apaolillo]

Second slice of the new-API refactor: parameter-space exploration becomes a first-class, pluggable value instead of being hardwired into the campaign classes. A RecordGenerator protocol (structural typing, like the core Benchmark and Executor protocols) produces the records a campaign explores; each records() call returns a fresh iteration.

Three finite generators land: CartesianGenerator wraps the existing cartesian_product utility, ListGenerator iterates pre-built records in order, and FilteredGenerator composes with any generator to keep only records passing a predicate, so a filtered cartesian campaign still declares what it explores instead of degrading to a flat record list.

Campaigns now build their records through a generator: CampaignTemplate accepts exactly one of variables or record_generator (falling back to a ListGenerator around the former), CampaignCartesianProduct declares a CartesianGenerator (wrapped in FilteredGenerator when filter_func is set), and every campaign exposes a record_generator property for the engine and later slices to read. Records are still materialized once at campaign construction, exactly where list(variables) happened before, so duration estimation keeps working and behavior is preserved; lazy, engine-driven generation (required for adaptive exploration, where the record stream depends on previous results) comes with a later phase.

The generators are re-exported from the top-level package as public API. Tests cover the generator implementations, the campaign wiring (including record equality with the legacy cartesian path), and an end-to-end run of a campaign built from an explicit generator.

[matsvanmolle]

LGTM