Reorganize `sentry-core` and `sentry`

We should rethink the separation between `sentry-core` and `sentry`.

This issue was prompted by a Slack discussion with @lorenzocian where we realized that some of the things in `sentry-core` likely don't make sense to be there. As we understand it, `sentry-core`'s main purpose is to offer library authors a way to instrument their libraries with Sentry, without actually offering the features for sending events to Sentry.

However, this architecture has some problems. Some types related to sending events (e.g. `ClientOptions` and `Client`) are defined in the `sentry-core` rather than in `sentry`. If the goal of `sentry-core` is to have a minimal API for library authors, these seem misplaced in that crate.

More fundamentally, we may wish to rethink whether the separation into separate crates makes any sense at all.

---

Let's rethink the separation, and refactor if needed.