LogEntryType registry (#4235)

Move display of LogEntry details from the `logentry_display` and 
`logentry_object_link` signals to a class hierarchy based approach. 
For each action_type, an instance of a subclass of `LogEntryType` 
is registered in the `log_entry_types` registry.

Analogous to EventPluginSignal, this registry is an `EventPluginRegistry`, 
so it keeps track of the plugin the LogEntryType is defined in.

---------

Co-authored-by: Raphael Michel <michel@rami.io>
Co-authored-by: Richard Schreiber <schreiber@rami.io>

doc/development/api/plugins.rst

@@ -121,6 +121,7 @@ This will automatically make pretix discover this plugin as soon as it is instal
 through ``pip``. During development, you can just run ``python setup.py develop`` inside
 your plugin source directory to make it discoverable.
 
+.. _`signals`:
 Signals
 -------
 
@@ -153,6 +154,25 @@ in the ``installed`` method:
 Note that ``installed`` will *not* be called if the plugin is indirectly activated for an event
 because the event is created with settings copied from another event.
 
+.. _`registries`:
+Registries
+----------
+
+Many signals in pretix are used so that plugins can "register" a class, e.g. a payment provider or a
+ticket renderer.
+
+However, for some of them (types of :ref:`Log Entries <logging>`) we use a different method to keep track of them:
+In a ``Registry``, classes are collected at application startup, along with a unique key (in case
+of LogEntryType, the ``action_type``) as well as which plugin registered them.
+
+To register a class, you can use one of several decorators provided by the Registry object:
+
+.. autoclass:: pretix.base.logentrytypes.LogEntryTypeRegistry
+   :members: register, new, new_from_dict
+
+All files in which classes are registered need to be imported in the ``AppConfig.ready`` as explained
+in `Signals <signals>`_ above.
+
 Views
 -----