We'll still need to call `Sentry.init` somewhere, but I don't think the
right place to do that exists yet.

For sending exceptions to Sentry. One method sends and silences the
exception, the other sends and re-raises it.

`Sentry.init` needed to be called before we used any Sentry methods, so
while it's a little bit gross, this ended up feeling like the right
place.

Our Helm chart already includes the SENTRY_DSN, SENTRY_CURRENT_ENV and
SENTRY_RELEASE in our job's environment, by the way, so Sentry should be
configured out-of-the-box. (Othewise, we'd supply configuration to
`Sentry.init`.)

Nothing's changed, I just spotted that this isn't needed

I might merge these commits later, but attempting to minimise noise in
the commits where I'm actually doing something

Send exceptions to Sentry and don't let them propagate any further.

I imagine this allowing us to add new SLI classes without any one class
preventing the others collecting their data.

But allow them to propagate so that they can result in a non-zero exit
code and so that they're also sent to Logit