Limit a QuerySet by CBAC (Shared ontology for object claims)

For example, the following use cases would need to limit objects by CBAC:

https://github.com/orgs/con2/projects/3/views/1?filterQuery=&pane=issue&itemId=46277628

In order for this to work, we need to define a shared ontology for object based access via CBAC.

For example, when a survey owner wants to see responses of a query, the claims tested by `graphql_query_cbac_required` are currently field oriented:

```
organization=tracon-ry
event=hitpoint2024
app=forms
view=graphql
operation=query
object_type=EventSurvey
slug=larp-survey
field=resolve_responses
```

And when a survey owner wants to download those same responses, this is used instead:

```
organization=tracon-ry
event=hitpoint2024
app=forms # FIXME missing (should be added)
view=forms_event_survey_excel_export_view
method=GET
path=/events/hitpoint2024/surveys/larp-survey/responses.xlsx
```

My initial thoughts on this are, that we should be able to differentiate at least the following actions:

* see the responses (either all or one) of a survey
* download the responses as excel of a survey
* delete a survey response

These suggest we should have at least `organization, event, app=forms, survey` (the latter being the slug of the survey) as claims to identify a survey, all surveys of an event, or all event surveys of an organization.

Furthermore, we need to differentiate `see responses`, `download responses` and `delete survey response` as some kind of `action`. (Name of the action claim? `action, operation`? Spelling of its values?

Likely we cannot tie these to RESTonomics, but neither can we tie them to GraphQLinquistics.

When we have such a shared ontology, then we can construct a `limit_queryset` that could look something like

```python
qs = limit_queryset(self.responses.all(), request.user, action="download responses")
```

that should introspect as many claims as can be introspecten and accept further claims as kwargs, ending up in a list of claims such as

```
organization=tracon-ry
event=hitpoint2024
app=forms
type=EventSurveyResponse # object_type/kind/model? is it better to identify by the parent or the list item type?
survey=larp-survey
action=download responses
```