Batch prefetching

[dxqb]

"Dataloader Threads" is a misnomer. It sounds like we are using multiple threads to load data. We actually don't:
It is the number of threads that are used to build the cache.

Loading from the cache is currently done sequentially in the training loop: load batch 1 - train batch 1 - load batch 2 - train batch 2 - ...

This can have a major performance impact if the cache lives on hdd.

This PR renames the "Dataloader Threads" to "Caching Threads" and introduces batch prefetching:
during training of batch 1, batch 2 is loaded from disk

@Calamdor

[dxqb]

• using prefetch when cache is disabled might cause issues. the text encoder and/or VAE run in parallel during the training step. That's probably okay, but they could theoretically also still run while the model is moved off GPU for sampling, backup, ...
  either add something to wait for the prefetcher, or disable prefetching when disk cache isn't used

[dxqb]

Claude: Heads up — the dataloader_threads → caching_threads rename's migration (__migration_10, the if "dataloader_threads" in migrated_data: migrated_data["caching_threads"] = migrated_data.pop("dataloader_threads") step) won't run for the built-in training_presets/#*.json files.

BaseTopBarView.__load_current_config forces loaded_dict["__version"] = default_config.config_version for built-in presets (files starting with #), on the assumption that they're "saved in the most recent version" — this skips the entire migration chain. The 21 built-in presets that still have "dataloader_threads": 1 will silently lose that value (the key is no longer in TrainConfig's fields, so it's ignored), and caching_threads falls back to its default of 2 instead.

Not data-destroying since 2 is a sane default, but worth either updating those 21 preset files to "caching_threads" directly, or keeping dataloader_threads as a deprecated alias read at load time.