add `extra` to the logger.

Allow for logging handlers to inspect the `request` and `status_code`, as Django does internally in places.

This allows for configuring LOGGING to do things like:
```
LOGGING = {
    ...
    'loggers': {
        ...
        'javascript_error': {
            'handlers': ['mail_admins', 'console'],
            'level': 'ERROR',
            'propagate': True,
        },
    }
}
```
the important part being `mail_admins`, which is configured as a handler that uses the `django.utils.log.AdminEmailHandler` class, though any handler class could theoretically make use of the `extra` values.

Thus, the endpoint for the error email (in our case, a ticketing system) now includes the WSGIRequest repr.
Pros:
 * all kinds of extra data, looks like the rest of the exceptions.
    * cookies
    * info about which server received this request
    * user agent (thus could be removed from the `logging.error` in the view)

Cons:
 * the WSGIRequest `path` attribute will reflect the JS-onerror endpoint, rather than the originating URL (which instead exists in the referrer, if given)