The function "potentiallyApplicableRulesets" is hot, and its results are stable.

From profiling, this is *very* slow, and it's easy to see why. The calls look like:

     Loading www.nytimes.com ->
          Load every image (20+ images at graphics8.nytimes.com)
	       Call potentiallyApplicableRulesets every time
	       	    Return the same result every time :(

Let's use a simple LRU cache to store those results.

This adds the MIT-licensed LRU cache from: https://github.com/rsms/js-lru

The cache isn't persistent (it's in memory, not LocalStorage or elsewhere),
so we don't have to worry about stale data when the extension updates.

Signed-off-by: Nick Semenkovich <semenko@alum.mit.edu>
Fix logic error in my prior commit

I wasn't reading carefully enough -- adds some comments explaining why we're
listening on send/rcv in the first place.

Signed-off-by: Nick Semenkovich <semenko@alum.mit.edu>
Clean up some tiny but annoying lint warnings

Some unused variables (and some forgotten ones).

Signed-off-by: Nick Semenkovich <semenko@alum.mit.edu>

Conflicts:

	chromium/rules.js
Set a more sane default log level

Logging /alone/ takes 50%+ of HTTPS Everywhere's profile time in Chrome (!)

Chrome will log & buffer console.log() even when the console is closed.

This means that for 99.9% of users (who never open the console), Chrome wastes
staggering amounts of time logging and buffering extremely verbose data.

For now, this just sets a default log level and includes adds the .warn() function.

TODO (Upcoming commit): Add a UI element to change the default log level.

Developers can simply type (in the console): DEFAULT_LOG_LEVEL=1;

Signed-off-by: Nick Semenkovich <semenko@alum.mit.edu>
Add MIT license note