Cleanup 2nd param to ReactEventEmitter.ensureListening

It was removed, so these callsites aren't actually doing anything.
Delete `throwIf`

Deletes `throwIf()` in favor of having one way to throw errors: `invariant()`
Batch Child Markup Generation

Setting `innerHTML` is slow: http://jsperf.com/react-child-creation/2

This reduces the number of times we set `innerHTML` by batching markup generation in a component tree.

As usual, I cleaned up the `ReactMultiChild` module significantly.

== Children Reconciliation ==

When a `ReactNativeComponent` reconciles, it compares currently rendered children, `prevChildren`, with the new children, `nextChildren`. It figures out the shortest series of updates required to render `nextChildren` where each update is one of:

 - Create nodes for a new child and insert it at an index.
 - Update an existing node and, if necessary, move it to an index.
 - Remove an existing node.

This serializable series of updates is sent to `ReactDOMIDOperations` where the actions are actually acted on.

== Problem ==

There are two problems:

 # When a `ReactNativeComponent` renders new children, it sets `innerHTML` once for each contiguous set of children.
 # Each `ReactNativeComponent` renders its children in isolation, so two components that both render new children will do so separately.

For example, consider the following update:

  React.renderComponent(<div><p><span /></p><p><span /></p></div>, ...);
  React.renderComponent(<div><p><img /><span /><img /></p><p><img /><span /><img /></p></div>, ...);

This will trigger setting `innerHTML` four times.

== Solution ==

Instead of enqueuing the series of updates per component, this diff changes `ReactMultiChild` to enqueue updates per component tree (which works by counting recursive calls to `updateChildren`). Once all updates in the tree are accounted for, we render all markup using a single `innerHTML` set.
Get rid of initializeTouchEvents

We don't need it any more, thanks to @yungsters's 4deb0d61. Before that we weren't getting click events regardless of whether touch events were initialized, which was (as far as I know) the only thing to be worried about with this change.

Test Plan:
On an iPad, verified that a single element can receive touchstart, touchmove, touchend, mousedown, mouseup, and click events all at the same time (with a single tap, no less!).