`domready`, resolves #851 and #853

This fixes both  #851 and #853. Here's a copy/paste of what's going on with `domready` from #853:

 1. Load http://jsbin.com/epejey/8 into any browser, excluding IE. The `domready` event fires extremely late, due to a really slow loading image. This is incorrect, as `domready` is supposed to fire when the document itself is ready to be manipulated (this is before images, stylesheets, and frames have finished loading). 

 2. The `DOMContentLoaded` event is incorrectly added in `event-ready-base.js`, when it should've been added to the core (addition of the `load` event is rightfully placed in core already, which is good). This means the `DOMContentLoaded` event won't get added until after the event module has loaded, and by then, it's too late.

 3. As a result of the aforementioned, `domready`'s callback won't fire until the page has completed loaded, images and all.

-------------------------------

As far as testing goes: the `domready` event isn't really tested in the library. Testing whether `domready` really fires is easy, but it is harder to test whether it fires *before* the `load` event, like it should. In order to do this, we would need a really large resource (an image, for example) and have it try downloading in the background. This will block the `load` event from firing. In addition to this, the test would need to be in a file of its own, as a unit test relying on image loading cannot be done in the midst of dozens of other tests. This might be more trouble than what it's worth.

--------------------------------

Credits to @kingback for providing the fix for this issue.