predefined report reasons & improved reporter UI

[rigelk]

As mentioned in #1781, predefined reasons might help triage reports. I also plan to add timestamps as potential additions to a report, to help pin down the relevant parts of a video, as well as a player within the report modal.

TODO:

• UI for predefined reasons within modal
• UI for video playback within modal
• client service
• backend API POST parameters
• backend API GET attributes
• backend API GET filtering
• UI for admin abuse list display
• UI for admin abuse list filtering
• models
• migration
• federation
• tests

closes #1781

[tcitworld]

Funkwhale uses hashtags to give a reason for the report IIRC.

[rigelk]

For reference, the abuse representation in Funkwhale is https://dev.funkwhale.audio/funkwhale/funkwhale/-/blob/develop/api/funkwhale_api/federation/serializers.py#L1728-1740, with a tag representation as follows:

{"type": "Hashtag", "name": "#{}".format(tag_name)}

In my current implementation I use name to store the predefinedReasonId, but maybe we could use another field for this.

[Chocobozzz]

Please add tests

[Chocobozzz]

Please add check-params tests to test predefinedReasons, startAt and endAt params.

After that, ready to merge 👍