Issue 189 - Implement API changes from #117, #153, #192 in libadblockplus

Tests had to be adjusted because an existing patterns.ini file with no data doesn`t trigger first-run actions any more - only a missing file does.

[Felix Dahlke, 2014-04-23 09:43:22]

Looks good, just one comment.

http://codereview.adblockplus.org/5740786045943808/diff/5629499534213120/lib/...
File lib/init.js (right):

http://codereview.adblockplus.org/5740786045943808/diff/5629499534213120/lib/...
lib/init.js:29: _triggerEvent("init",
require("filterStorage").FilterStorage.firstRun);
Also required below, I'd vote for doing this once above.

[Wladimir Palant, 2014-04-23 10:40:36]

http://codereview.adblockplus.org/5740786045943808/diff/5629499534213120/lib/...
File lib/init.js (right):

http://codereview.adblockplus.org/5740786045943808/diff/5629499534213120/lib/...
lib/init.js:29: _triggerEvent("init",
require("filterStorage").FilterStorage.firstRun);
On 2014/04/23 09:43:22, Felix H. Dahlke wrote:
> Also required below, I'd vote for doing this once above.

This isn't a real module loading mechanism here, modules load in a fixed order
as defined in the convert_js build step. We can move init.js below
filterStorage.js of course but that will mean that filterStorage.js initializes
before the code here has a chance to run. This will introduce a slight chance
for the "load" event to fire before we register the listener below. Nothing that
can't be fixed but before I open that can of worms I'll rather require() the
module twice.

[Felix Dahlke, 2014-04-24 11:11:41]

LGTM

http://codereview.adblockplus.org/5740786045943808/diff/5629499534213120/lib/...
File lib/init.js (right):

http://codereview.adblockplus.org/5740786045943808/diff/5629499534213120/lib/...
lib/init.js:29: _triggerEvent("init",
require("filterStorage").FilterStorage.firstRun);
On 2014/04/23 10:40:36, Wladimir Palant wrote:
> On 2014/04/23 09:43:22, Felix H. Dahlke wrote:
> > Also required below, I'd vote for doing this once above.
> 
> This isn't a real module loading mechanism here, modules load in a fixed order
> as defined in the convert_js build step. We can move init.js below
> filterStorage.js of course but that will mean that filterStorage.js
initializes
> before the code here has a chance to run. This will introduce a slight chance
> for the "load" event to fire before we register the listener below. Nothing
that
> can't be fixed but before I open that can of worms I'll rather require() the
> module twice.

Well, that's a leaky abstraction if there ever was one. I agree that it
shouldn't be fixed as part of this review though. I've filed a issue for
discussing this: https://issues.adblockplus.org/ticket/378