Features/registry

[steffencruz]

The goal of this PR is to introduce a registry data structure to manage both tasks and datasets.

• Adds a task and dataset registry so that direct references to task and dataset classes are reduced. This will make the management of tasks and datasets, including exposing and disabling them, simpler. It will also streamline task development and review by reducing the number of changed files for Task PRs.
• A further design improvement proposed in this PR enables a many-to-one mapping of datasets to tasks with a controllable way of selecting specific mappings.

[p-ferreira]

The way I see it, a Task depends on a Dataset to be created and a Reward model to be evaluated. Imho a config file could be a better place to position those configurations than raw python code, where the validator loads the definition of the "task framework" into the generic code that knows how to handle it.

[p-ferreira]

Besides minor logging and formatting changes, I believe this approach is less user friendly than relying in configs. This approach also don’t relate reward models to the task to be performed, which could be something to address in the future. In any case, it seems to be functional, if it’s currently working on prod and we have tests for it as it apparently is the case, we should be fine moving on with this approach.