This has been a source of great confusion for me. It makes no sense that
the API accepts multiple Exceptions per Event, while at the same time:

- Exception-specific properties (e.g. groupingHash) are Event-level
- All client's have a setting like ignoreException, without really
  explaining how that might apply to the multi-Exception Event (do you
  ignore if they all match? Any? Do you filter, then ignore if empty?)

Turns out, at least as far as I can tell, the multi-Exception interface
is a Ruby-specific affordance. It's to support Exception#cause[1]. Even
that library is oriented in a single-Exception way, then it attempts to
unwrap nested Exceptions at report-time. If it finds many levels, it
needs a way to include them all, so the interface for the API was bent
to accept exceptions (rather than accept Exception.cause :: Exception,
which would've been both *more* Ruby-inspired and, IMO, a better general
interface!).

[1]: https://github.com/bugsnag/bugsnag-ruby/blob/f8322960b5b2a9c7f9c60c2a68abddd9f24d5ec1/lib/bugsnag/report.rb#L174-L208

Haskell doesn't have this notion (at least, not in any kind of
first-class way). So we can basically take the same approach: pretend
the whole world is single-Exception, then wrap it up as a list at
report-time only.

The upside is we could avoid a documented caveat (updateException), an
ErrorCall (bugsnagShouldNotify), and we should now be able to resolve
Issue #26. The downside is we needed a manual ToJSON instance to perform
the translation. No big deal. We could've avoided even this by using
some kind of newtype, but that would've made the value-construction/use
more cumbersome, so a poor trade-off.

See #14.

Glob < 0.9.0 returns absolute paths, which means lookups with relative
keys fails if using that version.