Integrate EventProcessor chain into ScopeProvider

[stephanschuler]

Current situation:

The ScopeProvider has several "slots" of information, such as "environment", "tags", "release", "tags" and "user".

There's an individual chain of *Provider classes for each slot.
Every such class can add data.
Each provider is unaware of the data other providers contributed, as well as the data already present in the Sentry\Event during runtime. So those calls are more or less static, although they can depend on user input such as e.g. the currently logged in frontend user.

Obstacle:

1. There is no way of overruling existing data by reading it from the Event object, manipulating it, and adding it back to the event.
   Real world example: Replace the POST payload with an encrypted version of it.

   1. Try and recreate the POST body exactly like Sentry did (by copying Sentry code because this part is private).
   2. Overwrite every POST body attribute with null, hoping to eliminate existing data.
   3. Encrypt and export in a new POST body attribute.
      This isn't particularly confidence inspiring because every Sentry update might change the way this data is named slightly without me knowing I'm pushing unencrypted data to Sentry again.

2. Making changes in two slots at once isn't possible.
   The mentioned feature of encrypting POST body data should add a link to the neos backend, targeting a backend module where administrators can decrypt and review this data.
   This link should go into the "Extras" section, not into the POST body.

What should we do?

• Introduce the concept of EventProcessors.
• EventProcessors have a separate configuration section in the yaml file.
• The EventProcessor should take an Event and update it or replace it entirely.
• Make the NetlogixIntegraton walk through the chain of EventProcessors exactly where currently the ScopeProcessor is asked for collection slot data.
• Move all ScopeProvider::collect* methods into individual *EventProcessor classes.

This should, from the perspective of yaml configuration and interfaces in the "Scope" folder, with no breaking change while adding a new layer of event manipulation capability.