This is important so that any BeforeNotify behavior that changes aspects
of the Event that would cause it to be ignored are respected. The
trade-off is that we have to introduce an error call for the case of
multiple Exceptions per Event. It's incoherent to pair bsIgnoreException
with shouldNotify for a multi-Exception Event. Do we not-notify if any
are ignored? All?

In the future, we might want to either fully support multi-Exception
Events by changing the setting to bsFilterExceptions (another
BeforeNotify, which is nice), or fully *not* support it by changing the
type of BugsnagEvent to hold a single Exception (not a NonEmpty). The
former is a breaking change that will cascade throughout the library
with little benefit (it would require making beExceptions a normal list
and handling the empty case without the aide of types), and the latter
would preclude using this library to interact with the API directly,
because the types would disallow a valid use-case at that level. The
current error-compromise might be our best option, even long-term.

- Update LTS in default build
- Test multiple versions of GHC

We will rely on this minimum version to use a simpler import. It wasn't
much trouble to bring in the extra-dep on old resolvers. If it were (or
becomes that way in the future, or we get a user report about it), we
can use CPP to support older aeson -- I'm not against it outright.

Very strange error, not worth debugging for the not-latest build.

Weeder can't find the correct Cabal file. Unclear why, the last time
this was fixed by using STACK_YAML, which we're doing.