Remove data-reactid and traverse immediately after insertion instead

One part of #1550, code is not final.

Idea: Instead of appending `data-reactid` to each node we insert (costs quite a bit and clutters) and lazy filling the cache (more complex code and each traversed node comes with a higher cost). Instead, traverse the inserted nodes immediately after insertion and set a hidden `__reactid` directly on the node instead, by also traversing through the ReactComponent hierarchy at the same time. The gain of removing `data-reactid` negates the cost of the traversal (even significant performance boost in older browsers) and we gain an infinitely larger potential:

1. A clean DOM, even for server-rendered markup.
2. Rather than store `__reactid` on the DOM nodes, we can store a direct reference to the ReactDOMComponent during traversal.
3. Rather than use `nodeCache` to find the node, we can set `_rootNode` on each ReactDOMComponent during traversal.
4. Rather than explicitly register event listeners during creation, we can instead directly query the ReactDOMComponents.
5. We can have super cheap DOM node to ReactDOMComponent to DOM node.
6. We can very cheaply attach event listeners directly to the DOM nodes (scroll, load, error, etc).
7. We can deprecate React ID (which grow linearly and affect the GC) in favor of a simpler monotonic IDs (fixed), which should also positively affect the performance of communication with the web workers.
8. We have detailed information on the expected DOM hierarchy, we can selectively choose to patch or error when the browser has mucked with the DOM while also providing exact details.
9. We have the possibility to unbox or split textnodes for ReactTextComponent during traversal, possibly quite cheaply, which would do away with the spans.
10. We can deprecate RootIndex, there can no longer be conflicts between multiple server-rendered roots.
11. Most certainly more things...

The performance of this PR by itself is somewhere between measurably faster and measurably slower (but not significantly so!) in modern browsers it seems. While being more or less equal to significantly faster in older browsers. Two things to keep in-mind, the perf-tests does NOT include layout and rendering (which far overshadow React overhead and DOM construction). Also, as is apparent in #1550, if we take advantage of the possibilities this opens up, it seems we can even measurably improve performance across the board.

A bunch of the tests are currently broken because of two unrelated bugs; #1568 and #1569.

```
   raw     gz Compared to master @ 46de927a28eb788b4329589658dbd31a014e4edd
 -1948   -887 build/react-with-addons.js
  -315   -159 build/react-with-addons.min.js
 -1948   -872 build/react.js
  -314   -147 build/react.min.js
```