Proof of concept using chrome.streamsPrivate API

This method captures all application/pdf streams, loads the viewer
and passes the stream to the PDF.js viewer.

This commit shows a proof of concept using the chrome.streamsPrivate API.

Advantages of new method:
- Access to the response body of the original request, thus fewer
  network requests.
- PDFs from non-GET requests (e.g. POST) are now supported.
- FTP files are also supported.

Possible improvements:
- Use declared content scripts instead of dynamic chrome.tabs.executeScript.
  This allows the extension to render the viewer in frames when the
  extension is disallowed to run executeScript for the top URL.
- Use chrome.declarativeWebRequest instead of webRequest, and replace
  background page with event page (don't forget to profile the
  difference & will the background/event page still work as intended?).
Insert dummy content script at every location.

This is needed for propagating the extension's permissions
to the extension's iframe, in the rare event that the PDF is
loaded in a sub frame, and the extension does not have access to the
top frame. For instance, when a http:-PDF file is embedded in a
local file, while "Allow access to local URLs" is disabled.

Note: Propagating permissions by inserting content scripts is an
 undocumented feature (http://crbug.com/302548).

Whenever it breaks, the issue (cross-domain permissions for XHR)
can be solved by using a content script that gets the blob using
the XMLHttpRequest API, followed by `postMessage` (via transferables)
to efficiently pass the arraybuffer back to the PDF Viewer.
Use tab-specific stream storage

Also:
- Use webNavigation.getAllFrames to find out whether the navigation has
  already started. This is (at least) needed for top-level navigation to
  a stream. The webNavigation.onErrorOccurred event has become obsolete,
  and has been removed.
Work-around for http://crbug.com/276898

When a new incognito session is started, the onExecuteMimeTypeHandler event is
often not dispatched in time. Instead, it's triggered in the non-incognito profile.

This commit offers a work-around that allows new incognito instances to view PDF files.
Make streamsPrivate optional; remove manifest key

Use streamsPrivate API when available.
When the API is not available, the extension will still work on
on http/https/file URLs, but not for POST requests or FTP.

As of writing, the Chromium project has still not whitelisted
the PDF Viewer extension in the Chrome Web Store.
 (extension ID oemmndcbldboiebfnladdacbdfmadadm)
Request to whitelist PDF.js in Chromium:
 https://code.google.com/p/chromium/issues/detail?id=326949

Opera 19 has whitelisted the PDF Viewer extension from
 https://addons.opera.com/extensions/details/pdf-viewer/
 (extension ID encfpfilknmenlmjemepncnlbbjlabkc)
 (https://github.com/Rob--W/pdf.js/issues/1#issuecomment-32357302)

If you want to test the streamsPrivate feature in Chrome,
edit the build/extensions/manifest.json and add the "key" again
 (see this commit for the value of this "key" field).
Merge pull request #4126 from Rob--W/crx-using-streams-api

Chromium extension using streamsPrivate API!