Improvements catching images

[brianvanburken]

I've used and tested, for a month, my fork of the extension containing a lot of changes. During this period I tested improvements for the following goals:

1. catch more images with improved checking for cases;
2. better feedback when the extension is enabled/disabled based on the current page;
3. extension working all the time (bug reported in Extension occasionally stops working #23);

Also, to better understand the extension, I've added more documentation about cases and why it does some things a certain way.

For point 1 I've improved the shouldCompress.js with cases I came across. At the time of writing, I've used my fork for 32 days with the compression level set to 20% and have reached the following statistics: 55,747 images processed and 2.24GB data saved (91%). There is one case not added to this PR that catches more images: some images have a content type of application/octet-stream (example page: https://code.google.com/archive/p/repo-clean/).

Point 2, was tackled by also checking if the current page is from a private network or has a different protocol (for pages like about:config etc.).

Point 3, seems to be resolved. During my 32 days, I've never caught the bug. Before I caught it within two weeks. More testing is needed. The problem, from my debugging a lot, seems to originate from attaching and detaching the listeners. In this PR, I attach the listeners once on startup and keep it that way. It does use a bit more memory and CPU when disabled (since it still listens to images). But, this only minimally since we exit early in the onBeforeRequest listener by checking if the extension is enabled. If the extension is disabled/removed by the user, the browser will clean up automatically (tested by adding debug points and disabling/removing the extension).

[mandaputtra]

Just found some typos

[ayastreb]

This looks great, thanks for contributing again!