simplify registry publishing workflow

[pablochacin]

Currently, when the registry.yaml is updated, three jobs are executed:

1. The registry is processed, the extensions are linted, and an updated version of the registry is generated
2. The API files are generated. This includes the catalog.json, a critical piece for the binary provisioning service, which supports k6's automatic extension resolution (accessed at https://k6registry.k6.io/catalog.json), but also other subsets of modules and metrics.
3. The wiki is published with human-readable information about the registry, including statistics.

This process is complex and has multiple moving parts, including data extraction and transformations using templates.

Most of these files are non-critical for the k6's automatic extension resolution feature. Moreover, the API is not used in any existing or planned process. The Wiki contains statistics that do not inform any existing process.

Also, as now all extensions in the registry are supported, they are part of the Grafana documentation

We propose the following simplifications:

• Remove the generation of the API files until a use case appears that justifies it
• Publish the catalog.json as part of the core registry update job
• Remove statistics from the wiki. They are not informative now that the grades have been removed from the registry
• Keep the wiki as a human-readable version of the registry and focus on reporting issues in the extensions. This information should be moved to a grafana dashboard following the same approach for security vulnerabilities, SLOs, etc.