Add a collection with datasets infos
While working on enabling private datasets (#39) under conditions (isPro, isEnterprise), I thought we missed a place where we control the access to the dataset.

I think the first step in the DAG, instead of dataset-config-names, should be more about the dataset characteristics: if it's private or public, maybe if it's gated (not sure if it's useful info), if the user is pro or if the org is enterprise, if the viewer is disabled through the README (see https://github.com/huggingface/datasets-server/issues/2207), if the dataset is in the block list.

All that information could go to a new step called `dataset-status` or something similar.

The content could be:

```json
{
  "dataset": "namespace/dataset",
  "private": true,
  "proUser": false,
  "enterpriseOrg": true,
  "disabledFromReadme": false,
  "gated": false,
  "blocked": false,
}
```

And a second step, called `dataset-enabled`, that would depend on `dataset-status`, and would return:
- 200 `{enabled: true}` if all the conditions are met
- 404 if we don't want to disclose the existence of the dataset, or if it does not exist
- 501 if it's not implemented
- 403? 404? if the dataset viewer is not enabled (private dataset, no pro user/enterprise org)

Then, the following steps would propagate the error if so, or if 200, will act as currently.

I think it's clearer to have two different steps: one to collect the data, another one to take a decision on this basis. We could also have everything in one cache entry, but I think the logic for maintenance would be harder (we would have to add info like: is that dataset private, is the user pro, etc. in the error details, or in the content, etc. to be able to check them regularly)
Add a collection with datasets infos: While working on enabling private datasets (#39) under conditions (isPro, isEnterprise), I thought we missed a place where we control the access to the dataset.

I think the first step in the DAG, instead of dataset-config-names, should be more about the dataset characteristics: if it's private or public, maybe if it's gated (not sure if it's useful info), if the user is pro or if the org is enterprise, if the viewer is disabled through the README (see https://github.com/huggingface/datasets-server/issues/2207), if the dataset is in the block list.

All that information could go to a new step called `dataset-status` or something similar.

The content could be:

```json
{
  "dataset": "namespace/dataset",
  "private": true,
  "proUser": false,
  "enterpriseOrg": true,
  "disabledFromReadme": false,
  "gated": false,
  "blocked": false,
}
```

And a second step, called `dataset-enabled`, that would depend on `dataset-status`, and would return:
- 200 `{enabled: true}` if all the conditions are met
- 404 if we don't want to disclose the existence of the dataset, or if it does not exist
- 501 if it's not implemented
- 403? 404? if the dataset viewer is not enabled (private dataset, no pro user/enterprise org)

Then, the following steps would propagate the error if so, or if 200, will act as currently.

I think it's clearer to have two different steps: one to collect the data, another one to take a decision on this basis. We could also have everything in one cache entry, but I think the logic for maintenance would be harder (we would have to add info like: is that dataset private, is the user pro, etc. in the error details, or in the content, etc. to be able to check them regularly)