Refactor gegevensgroep/gegevensgroepserializer implementation

[sergei-maertens]

Currently the GegevensGroepSerializer works by invoking multiple setattr calls on the instance after calling the parent create() or update() methods. This is done in an atomic DB transaction, which has some drawbacks:

• it's a custom implementation to manage "gegevensgroepen"
• It requires special attention w/r to the serializer/schema generation for the API spec
• performance is excessive: 2 queries are needed for the transactional behaviour + at least 1 query for the update by the .save call
• saving may trigger excessive ETag updates with duplicated queries/cycles

The performance problems have been observed in the Zaak create endpoint in Open Zaak, see open-zaak/open-zaak#1271

This should instead be reworked according to the following ideas/principles:

• Build this on top of drf-serializers without custom setters/getters/descriptors. A list of field names should be sufficient to generate a serializer on the fly with source="*" and the correct nested serializer field mapping via foo = serializser.Field(source="some_prefix_foo") (see the ModelTranslationSerializer in Open Forms for an example)
• Remove the custom schema generation utils - genering a proper serializer on the fly should result in the correct schema
• There's no guarantee anymore that all fields inside are required (the purpose of gegevensgroep was to treat it as an atomic unit). Instead, define the constraints properly in the database using models.CheckConstraint for data integrity purposes
• Document the recommendation that the outer view(set) create should enforce transaction.atomic - refactoring in proper serializer fields with source attributes should automatically do the attribute assignment, which allows us to drop the custom create and update implementation. This also removes the need for the mixin.