Consider using the landscape YAML file as data source

Hi 👋

We've started looking into this and there are some points we'd like to comment with you 🙂

- Multiple repositories per project

In the `landscape.yml` file, each project contains a repo url. In CLOMonitor, projects can have multiple repositories (they do often), so we'd need to get that information from the landscape.

- Additional information per repository

This point is related to the previous one. In addition to being able to list multiple repositories per project, we also need some extra information defined per repository in addition to the url. At the moment this would be mainly for the [checks sets](https://clomonitor.io/docs/topics/checks/). In CLOMonitor, [each repository is assigned one or more checks sets](https://github.com/cncf/clomonitor/blob/4d705ce5bb1ce621b14e31147c20d6e4e933544f/database/data/cncf/repositories.csv), which defines the checks that will be run on it. This information should also be available in the `landscape.yml` file.

- Missing data

There are some projects (~25, not always the same ones) that miss some information, like the `accepted_at` or the `devstats_url` fields. Some of the features in CLOMonitor rely on them, so it'd be great if they could be added.

There will probably be some more points to address, but this should be a good start.

Thanks!

BTW do you think we could display a [CLOMonitor report summary](https://github.com/artifacthub/hub#clomonitor-report) per project on the Landscape page somehow? 😇

/cc @caniszczyk @jeefy

Start by comparing the landscape.yml data source with database/data/cncf/repositories.csv and the linked checks-set documentation. Done means CLOMonitor can consume multiple repositories per project, per-repository check-set information, and the missing project fields identified in the issue.

Written by the indexing model from the issue text.