Add a dv flow that bundles child configs of different flows

Start by tracing _load_cfg and deploy_objects to understand mixed child construction and job collection, then inspect OneShotCfg.gen_results and the existing vplan_sources() paths. Define the dv primary config around its child restrictions, annotation job, result summary, and CLI handling. Done means both children run, one plan is scored from all evidence, standalone flows remain unchanged, and unsupported options fail with actionable messages.

Part of lowRISC/dvplan#129, and the point of the whole exercise on this side. Depends on the source-naming, formal-annotation and per-child-tool issues.

One command should run a block's simulation regression and its formal regression and score one vPlan from both. Something like:

{
  flow: dv
  name: hmac_dv
  vplan: "{proj_root}/hw/ip/hmac/data/hmac_vplan.hjson"
  dut_instance: "tb.dut"
  use_cfgs: [
    { cfg: "{proj_root}/hw/ip/hmac/dv/hmac_sim_cfg.hjson",  tool: xcelium  }
    { cfg: "{proj_root}/hw/ip/hmac/fpv/hmac_fpv_cfg.hjson", tool: vcformal }
  ]
}

Most of the machinery is there. _load_cfg resolves each child's class from that child's own flow key, so mixed children are already constructible, and deploy_objects gathers jobs from every child. What blocks it is that each primary class assumes its children share its own type, such as the TypeError in OneShotCfg.gen_results.

Scope

• A primary-only config class for flow: dv. It has no build or run jobs of its own, requires use_cfgs, and refuses to be a child of another primary config.
• It owns the single vPlan annotation job, which depends on every child's terminal jobs and reads the concatenation of every child's vplan_sources(). One invocation of DVPlan, because whether an item is unmeasurable is judged over the whole set of sources a run is given.
• A results summary holding each child's own table plus the plan's score. Children keep their existing per-flow reports.
• Command line behaviour on a bundle needs deciding and documenting: reject --tool, since it cannot mean one thing across two flows, and settle what -i, --cov, --build-only and --purge mean when they reach children of different flows. Rejecting with a clear message is a fine first answer for any of them.
• A child naming its own vplan while the bundle names one is a conflict, so warn and let the bundle win.

Done when

• A bundle config runs both children and writes one annotated plan scored from the simulation report, the formal report and the evidence file.
• Each child still runs standalone, unchanged.
• The unsupported command line combinations fail with a message that names what to do instead.