Configuration for errors is complex and non-intuitive #734
Description
To register errors for (de)serialization to the front-end, the configuration is complex and results in very large configuration files. For example, when an error is thrown from the feature domain/activity/add the file where the error is thrown needs to be registered (as private) in the segment.json and index file. But when there are other files in the feature that might go to other features, these files also need to be added. This leads to a chain reaction and a puzzle to run through every feature to figure out what calls what.
This is too complex and tedious to make this work. We need to have something that is easier to understand and confure.
One of the possible solution directions is to decouple the registration of errors (classes, to be more specific) from the segmentation configuration. The only reason to register a class is for the serializer to know how to (de)serialize classes.
As we still don't want the errors to be serializable in every segment, we need to have some configuration option to let the serializer know what it is allowed to (de)serialize.