Change /parquet-and-dataset-info processing step
For now, /parquet-and-dataset-info is run for a dataset. But as it's a loop on all the configs, we could instead decide to turn it into a "config" job, ie. make it depend on the result of /config-names, and launch a job for each of the configs.

This means doing the same for the dependent processing steps: /dataset-info, /parquet, /sizes.

This means also being able to answer the endpoints to both:
- ?dataset=dataset&config=config: directly from the database
- ?dataset=dataset: an aggregation of the config responses. For this point, the discussion is the same as https://github.com/huggingface/datasets-server/issues/734: should we have a dedicate worker, or compute on the fly?

The benefit would be to decouple how different configs from the same dataset are treated, in particular, let a config work even if another one is broken.

A specific challenge is how to store the parquet files. Currently, we have a dedicated "branch" (refs/convert/parquet), with an arborescence with one subdirectory per config, and parquet files inside for all the splits of the config. I think this schema would still work well, but as it's versioned with git, maybe some details could arise (concurrent access? it should be handled with the [`parent_commit`](https://github.com/huggingface/datasets-server/blob/main/workers/datasets_based/src/datasets_based/workers/parquet_and_dataset_info.py#L625) parameter, at least an error would be thrown in case of concurrent write attempts).

---

Subtasks (should be implemented in that order):

- [x] https://github.com/huggingface/datasets-server/issues/863
- [x] https://github.com/huggingface/datasets-server/issues/864
- [x] https://github.com/huggingface/datasets-server/issues/865
- [x] https://github.com/huggingface/datasets-server/issues/866
Change /parquet-and-dataset-info processing step: For now, /parquet-and-dataset-info is run for a dataset. But as it's a loop on all the configs, we could instead decide to turn it into a "config" job, ie. make it depend on the result of /config-names, and launch a job for each of the configs.

This means doing the same for the dependent processing steps: /dataset-info, /parquet, /sizes.

This means also being able to answer the endpoints to both:
- ?dataset=dataset&config=config: directly from the database
- ?dataset=dataset: an aggregation of the config responses. For this point, the discussion is the same as https://github.com/huggingface/datasets-server/issues/734: should we have a dedicate worker, or compute on the fly?

The benefit would be to decouple how different configs from the same dataset are treated, in particular, let a config work even if another one is broken.

A specific challenge is how to store the parquet files. Currently, we have a dedicated "branch" (refs/convert/parquet), with an arborescence with one subdirectory per config, and parquet files inside for all the splits of the config. I think this schema would still work well, but as it's versioned with git, maybe some details could arise (concurrent access? it should be handled with the [`parent_commit`](https://github.com/huggingface/datasets-server/blob/main/workers/datasets_based/src/datasets_based/workers/parquet_and_dataset_info.py#L625) parameter, at least an error would be thrown in case of concurrent write attempts).

---

Subtasks (should be implemented in that order):

- [x] https://github.com/huggingface/datasets-server/issues/863
- [x] https://github.com/huggingface/datasets-server/issues/864
- [x] https://github.com/huggingface/datasets-server/issues/865
- [x] https://github.com/huggingface/datasets-server/issues/866