Tell Sentry about all raised Responses

And tag sentry entries with a response code (1xx, 2xx, ... 5xx, n/a).
We're using barely any of our sentry quota, so we may as well start
logging more stuff there (assuming it doesn't affect performance, but
I can't imagine that sentry is our bottleneck).

This came up because we were trying to debug a 403 that @zwn is seeing
with trying to update his take. We're not sure where it's coming from
and right now we're not even sending that to stdout. With this change we
should at least an exception reference ID on stdout and the full info in
Sentry.
Trim whitespace
Treat SENTRY_DSN like other envvars

For whatever reason we were reading SENTRY_DSN out of the enviroment
differently than other variables.
Beef up Sentry logging

 - use `level` properly (replaces 5xx-style response codes)
 - use `response code` tag for full response code (500, not 5xx)
 - fold non-Response exceptions under 500
 - tag with username
Correct and clarify comment about level
Drop back to just two levels, debug and fatal

This is after conversation in #sentry IRC.
Drop back to only telling Sentry about exceptions

Based on discussion on and linked from #1560, I am dropping back to only
logging true exceptions (including raised Responses >= 500). The
substantive addition on this PR is now to include information about the
current user with Sentry events. We're back to going with the Sentry
default behavior for level, and no knowledge of the response code past
the first >= 500 filter.
Merge pull request #1560 from gittip/log-more

add info re: user to Sentry exception logging