FEAT: DatasetConfiguration Refactor

[rlundeen2]

DatasetConfiguration worked well for the first scenarios but strained as we added more: garak.encoding needs seed prompts, jailbreak needs two datasets (the harms and the jailbreaks themselves), psychosocial ties datasets to techniques, and other Garak scenarios want more flexible types. This PR refactors DatasetConfiguration to fit these diverse scenarios while simplifying the overall structure.

How it works now:

• On-demand fetching via the provider — if a configured dataset isn't in memory, it's fetched from the registered SeedDatasetProvider and stored, so you no longer need the load_default_datasets initializer on startup unless you want to preload.
• Simpler structure — a single DatasetConfiguration base plus DatasetAttackConfiguration (the default most scenarios use); the earlier typed subclasses and parallel get_seeds getters were dropped.
• Compound datasets — CompoundDatasetAttackConfiguration combines several configs and samples across them, so a scenario like encoding or jailbreak can draw from multiple datasets at once (with per-dataset or global max_dataset_size).
• Composable validators — constraints run against the fully resolved dataset before max_dataset_size sampling, so they describe the dataset itself rather than a sampled subset. Non-emptiness is enforced by default; scenarios can add others (seed type, harm categories, allowed names, inline-vs-named).
• Inline or named seeds — each resolved dataset carries a DatasetSourceKind (inline vs. memory), letting a scenario accept seeds directly (e.g. CLI --objectives) or require named datasets.
• Loud failures — resolution and fetch errors raise DatasetConstraintError naming the dataset and the reason instead of silently warning or returning empty.

Scenarios resolve through two getters — get_seed_attack_groups_async and get_attack_groups_by_dataset_async. All scenario unit tests pass.

[romanlutz]

I'm a bit worried about datasets we pulled into DB in the past that need updates (eg in the context of standardizing harm categories, or fixing metadata fields). Similarly, what happens to live datasets like threat feeds (think Odin or others).

How do we make sure they get refreshed?

[rlundeen2]

I'm a bit worried about datasets we pulled into DB in the past that need updates (eg in the context of standardizing harm categories, or fixing metadata fields). Similarly, what happens to live datasets like threat feeds (think Odin or others).

How do we make sure they get refreshed?

Good idea to include; I would separate from this PR but there are a couple solutions I like;

1. We could add an init parameter to this class that always refreshes
2. we could add an initializer that refreshes existing datasets that haven't been refreshed in X days (or refreshes all if that is 0)

I like #2 more; I created an item in proposed and linked to this