HTTP 304 responses not handled correctly

This is a spinoff from legacy/trac#21396 (moved). While testing gk's fix for that bug, Kathy and I noticed messages like the following on the error console:

15:09:57.836 NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIHttpChannel.getResponseHeader]1 content-policy.js:99:0

It turns out that this is caused by responses that have an HTTP status code of 304 ("Not Modified"); we saw them consistently when we reloaded the browserleaks.com page (which makes sense, since the browser sends conditional GET requests in that situation). These kinds of responses do not have a Location header.

We should modify the Torbutton code in src/components/content-policy.js to add a try/catch around the call to getResponseHeader() and not log anything if the response's status code is 304 (we probably want to log something in all other cases).

This is not urgent since it is not a new problem, but it would be good to fix it soon.