chore: configure Sentry environment

[gmaclennan]

This PR configures the environment string for Sentry bug reporting.

The Sentry UI separates issues by environment. It is a free-form string.

This is helpful so that we can easily see which issues are coming from actual production builds vs development builds.

I am using 3 environments:

• development: This is for any development builds or prerelease builds.
• qa: This is for any release candidate builds
• production: This is for any production builds that are released to the public.

In the future we can decide if we want to separate development and prerelease builds into different environments if helpful.

This PR also uses the applicationId to determine whether to print Sentry debug information, rather than the APP_VARIANT env, which was not being reliably set in builds.

[gmaclennan]

@ErikSin @achou11 I've just been browsing Sentry, and I think incorporating this change into the MVP is going to make it a lot easier to use Sentry to track down production bugs. Since we are delaying MVP a bit and still have a round of QA planned, what do you think about including this PR in MVP?

[achou11]

@ErikSin @achou11 I've just been browsing Sentry, and I think incorporating this change into the MVP is going to make it a lot easier to use Sentry to track down production bugs. Since we are delaying MVP a bit and still have a round of QA planned, what do you think about including this PR in MVP?

definitely in favor of it 👍