Check domWindow.document.documentURIObject against originalURI

We have a [Firefox extension](https://www.zotero.org/) that implements a custom protocol handler that returns `nsIFileChannel`s and then sets `channel.originalURI` back to our custom `zotero://` protocol. (It looks like pdf.js uses a similar approach.) In most places, these operate as if the same content had been served from a `file:///` URI, but they break pdf.js with the error:

```
SyntaxError: JSON.parse: unexpected character @ resource://pdf.js/web/l10n.js:14
```

This error appears to arises the extension isn't registering an event listener for the window. The problem seems to be that pdf.js checks that `document.documentURIObject` matches the request URI. In our case, it doesn't, because the request URI is the `file:///`URI, but the document URI is the `zotero://` URI, and so `domWindow.document.documentURIObject.equals(aRequest.URI))` is false.

Checking against both `aRequest.originalURI` and `aRequest.URI` fixes this and restores interoperability between pdf.js and our extension. This seems to make sense given that the [documentation for nsIChannel](https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsIChannel) states:

> [originalURI] is also used as the RI of the document resulting from the channel, unless the channel has the LOAD_REPLACE flag set.

However, I'm not completely positive what issue this check is addressing in the first place, so someone more knowledgeable on these matters should double-check that this won't have adverse consequences.