The Logger now logs to `console.log` exclusively.

Errors are reported using `captureException`, and non-errors are added
as breadcrumbs. This means the non-error events won't be directly sent
to Sentry, but they will be included as context for any errors that do
occur.

The sentry configuration is mainly in the `sentry.debug.properties`
file. The only config outside of that file is the DSN used for
reporting errors, which is hard-coded in the `setupSentry.js` module.

There are three separate sets of config: default, debug, and release.
The default config is missing the auth token, so it can't be used to
publish source maps. However, builds that use the default config will
still correctly report errors to the `test-metamask-mobile` Sentry
project.

The debug config is identical to the default config except that it
includes the auth token. The debug config is for publishing any
non-production builds (e.g. testing, pre-releases).

The release configuration is to be used for production builds only.
This is the only config that sends errors to the `metemask-mobile`
Sentry project.

The debug and release config files have not been added to the repo.
They are automatically instantiated from the example files if the
`MM_SENTRY_AUTH_TOKEN` environment variable is set. Setting this
environment variable in CI should allow publishing from CI.

Closes #1321

The SENTRY_PROPERTIES environment variable is used at different
directory levels in the Android and iOS builds respectively; it's
used one level down with iOS, but two levels down for Android. This
means the properties path used is incorrect on iOS at the moment.

Instead an absolute path is now used, to prevent any such errors in the
future.

The error message for the missing auth token has been improved as well.

The properties file is now checked to ensure the auth token is present,
so the build can fail early rather than partway through.

The logic for handling the auth token has been moved to a separate
function as well, so it can be shared between the release and
prerelease builds.

The Sentry environment is set to `local` by default (e.g. for dev
builds), but the build script now requires it to be explicitly set for
release builds. This is to ensure it isn't missed in the production
builds, which are done manually.

Whenever using the `throw` keyword or calling `reject` in a Promise,
the value passed should be an Error. Various tools expect thrown
"errors" to be errors; this is the convention. Using Error types is
also more useful for debugging, as they have stack traces.

`Logger.error` now expects an actual error object as the first
argument. This allows us to submit proper Errors with stack traces to
Sentry. The second parameter is an optional set of extra data, which
gets attached to the Error and is viewable on Sentry in the "Additional
Data" section of the error report.

Unfortunately any messages added to contextualize errors had to be
submitted as extra data instead of as a wrapper Error. Wrapper error
types provide for a richer debugging experience in general, because
you get additional context for the error plus an additional stack trace
to help trace the flow of the error. Sentry even has an Integration
meant to facilitate this pattern, the `LinkedErrors` integration.
But unfortunately that integration doesn't seem to work with React
Native, so that option was off the table.

The most recent Sentry packages have better support for capturing
native crashes on Android. I had held off on this update at first
beceause I thought it required React Native >= 0.60, but apparently
not. It still works on 0.59, just not as well (no sourcemaps)

It was expecting an alphabetical key instead of an alphanumeric one.