Backstage integration for Knative Eventing

**Problem**
[Backstage](https://backstage.io/), the internal developer portal, could be a very useful way to spread the usage of Knative Eventing.

While we're working on Event Discovery ([issue](https://github.com/knative/eventing/issues/4892), [project](https://github.com/orgs/knative/projects/62)) feature, we realized it can be very useful if the developers can discover the `EventType`s in Backstage, with their metadata (docs, schema, etc.).

Similarly, it might make sense to show the sources/sinks/services/etc.. Perhaps in a topology view with connections, in a list view without connections but discoverable.

Furthermore, this integration can be even extended to an integration with Knative Functions. It can be possible to select an `EventType` and create a consumer/producer [template](https://backstage.io/docs/features/software-templates/). The outcome would be a Knative Functions project with some of the implementation filled for the `EventType`.

Some important aspects:
- Backstage is a company-wide tool. It can have multiple Kubernetes clusters connected. This means, for example, to show the available `EventType`s, implementation needs to visit multiple clusters and/or ask for user's cluster selection.
- Backstage is not a replacement for all the UIs out there (Kubernetes console, etc.). Don't assume this will be the ultimate place to manage Brokers/Triggers/Sources/etc.
- Backstage traditionally displays the read-only information.