Discovery of Events in the broker/channel status

Feature Track document: https://docs.google.com/document/d/1vN-xd6yuTFVCgXrMSJVjHK-0U1yuXy_KIAf1Zfn2vjk/edit

**Problem**

The events processed by a broker/channel can be monitored by looking what `event type` is available, for a given broker/channel.

For instance, take this list of event types:

```
k get eventtypes.eventing.knative.dev
NAME TYPE SOURCE SCHEMA REFERENCE NAME REFERENCE KIND DESCRIPTION READY REASON
et-my-broker-68c23082bef5cc5a5650b2a4164581e1 foo.bar my/fancy/command/ my-broker Broker Event Type auto-created by controller True
et-my-broker-b8067eff8a782a7560c3136744d077b3 fooz.barz my/curl/command my-broker Broker Event Type auto-created by controller True
et-my-broker-dc90e945469d1db5a57c95d98ebb380f foo.bar my/curl/command my-broker Broker Event Type auto-created by controller True
et-testchannel-c44c6680141ffe5498059f8a0bfd6bfa foo.bar my/curl/command testchannel InMemoryChannel Event Type auto-created by controller True
```

In this example we can see that the `my-broker` has the following events:
* `foo.bar`
* `fooz.barz`
* `foo.bar`

We can also just filter the results by just asking for the value of the `type`, for the `my-broker`, like:

```
k get eventtypes.eventing.knative.dev -o json | jq '.items[] | select(.spec.reference.name == "my-broker") | .spec.type'

"foo.bar"
"fooz.barz"
"foo.bar"
```
but that is quiet a complex query. **However** this still contains duplicate event types, coming from different `source` URIs.

Adding a few more tools, you get a deduplicated list:
```
k get eventtypes.eventing.knative.dev -o json | jq '.items[] | select(.spec.reference.name == "my-broker") | .spec.type' | sort | uniq

"foo.bar"
"fooz.barz"
```

## Event list via Broker/Channel status

It would be nice if that information would be part of the status, instead of performing such a "query'.

For instance:
```yaml
apiVersion: eventing.knative.dev/v1
kind: Broker
metadata:
name: my-broker
# ...
status:
events:
- "fooz.barz"
- "foo.bar"
```

The events on the status would be a basically a simplified view, for a specific broker/channel, of its referenced `EventType` objects. However we would need to _deduplicate_ event types, to avoid that this status list has `n` "ping events", b/c we have "n" ping sources pointing to the broker/channel.

## RBAC

Another benefit is that the `status` subresource allows a more finegrain access control, so we can allow 3rd parties to just query the event types of a given broker/channel. Little POC by @aliok done: https://gist.github.com/aliok/aeffa1f9da09e2b794b771ac7c888266

**[Persona:](https://github.com/knative/eventing/blob/main/docs/personas.md)**
developers

**Exit Criteria**
A measurable (binary) test that would indicate that the problem has been resolved.

Start with the linked Feature Track document and Aliok's RBAC proof of concept, then inspect the Broker, Channel, and EventType status APIs in the repository. Define how status should expose a deduplicated list of referenced event types and how access to that status is controlled; done means the behavior has measurable tests and satisfies the stated exit criteria.

Written by the indexing model from the issue text.