In order to improve Sentry's grouping of errors, we want to make
use of the `backtrace_cleanup_callback` introduced in 3.1.0:
getsentry/sentry-ruby#1011

`backtrace_cleanup_callback` automatically uses a
[customised version of Rails::BacktraceCleaner](https://github.com/getsentry/sentry-ruby/pull/1011/files#diff-c01d5cbc846720e47a4185cb501a55225247ec698aa169b0a2773ca9b65ae35dR4-R29)
if we don't specify our own. It means that for stack traces like:

`app/views/welcome/view_error.html.erb in _app_views_welcome_view_error_html_erb__2807287320172182514_65600 at line 1`

...these lines get normalised to:

`app/views/welcome/view_error.html.erb at line 1`

So if the same `ActionView::Template::Error` error happens twice,
it will now be grouped instead of erroneously treated as separate
errors.

This behaviour differs from the [native `Rails::BacktraceCleaner`](https://github.com/rails/rails/blob/b66235d432d0505857ff667e0a1ddecfb5640a56/railties/lib/rails/backtrace_cleaner.rb),
which has 'silencers' that remove any "framework trace" from your
stacktrace, leaving only the "application trace" behind. This
would actually be beneficial for grouping, as Sentry is very
sensitive to stack traces that differ only slightly, which can
happen when a dependency is updated or a Ruby version is upgraded.

We could specify sentry-raven to use the Rails backtrace cleaner like so:

```ruby
config.backtrace_cleanup_callback = lambda do |backtrace|
  Rails.backtrace_cleaner.clean(backtrace)
end
```

...however, this is not _only_ used for the comparison, but would alter
the stacktrace itself, meaning we lose key diagnostic information.
This isn't a price worth paying for the sake of 'neatness' in our
Sentry groupings.

Trello: https://trello.com/c/NZNjFHWO/2162-5-improve-sentrys-grouping-of-exceptions