We want to upgrade the version of the Sentry gem we're currently using
to the latest version. However, this makes some breaking changes. One of
the biggest for our purposes is that it no longer supports processors -
these were classes to pre-process the event hash before sending to
Sentry.

In the latest version, these are no longer available, but we can still
use any logic we like in a custom `before_send` hook. So we can manually
chain our existing processors there. However, there's a catch:
processors in the current version take an event hash, but the
`before_send` hook takes an Event object. (Raven::Event in the current
version, Sentry::Event in the new one.)

This change adds a feature flag - sentry_processors_before_send - that
defaults to off. When it's off, we use the processors as we do now. When
it's on:

1. All the processors become no-ops when called as processors.
2. We enable them in a `before_send` chain through a different
   interface.

Because they take a different type of argument, this makes the
processors in this change a little ugly. We can tidy that up once we've
validated this feature flag in production, even before upgrading the
gem. We also add specs to test each processor both with and without the
feature flag enabled.