split add-ons into subsections

In preparation for documenting `classSet` add-on.
add docs on `classSet` add-on
update add-ons docs based on feedbacks

- Overview of add-ons for the add-ons page.
- Better title for `ReactLink`.
- Nicer code format for classSet example.
- Better explanation for `classSet`.
Set docs menu item to active when viewing a “tips” page
utils.* is now used everywhere
Rename receiveProps to receiveComponent

This renames receiveProps and changes it to take the next component to copy props from instead of just the props. That is,

  component.receiveComponent(nextComponent, transaction)

instead of

  component.receiveProps(nextComponent.props, transaction)

This is a precursor to adding contexts, which will also need to get propagated just like props. This change allows ReactCompositeComponent to override `receiveProps` and do something like

  this._pendingContext = nextComponent.context;
Remove Obsolete IE8 Compatibility Code

See the TODO comment. Synthetic events have shipped and this is no longer necessary.
Better error message for renderComponentToString()

Reported on Twitter by AirBnb (who are integrating React into their open-source JS framework). They made a mistake and passed a string in as the
component. We should have a better error message for that.
Contexts

Summary:
adds `this.context` which you can think of as implicit props, which are passed automatically down the //ownership// hierarchy.

Contexts should be used sparingly, since they essentially allow components to communicate with descendants (in the ownership sense, not parenthood sense), which is not usually a good idea. You probably would only use contexts in places where you'd normally use a global, but contexts allow you to override them for certain view subtrees which you can't do with globals.

The context starts out `null`:

  var RootComponent = React.createClass({
    render: function() {
      // this.context === null
    }
  });

You should **never** mutate the context directly, just like props and state.

You can change the context of your children (the ones you own, not `this.props.children` or via other props) using the new `withContext` method on `React`:

  var RootComponent = React.createClass({
    render: function() {
      // this.context === null
      var children = React.withContext({foo: 'a', bar: 'b'}, () => (
        // In ChildComponent#render, this.context === {foo: 'a', bar: 'b'}
        <ChildComponent />
      ));
      // this.context === null
    }
  });

Contexts are merged, so a component can override its owner's context **for its children**:

  var ChildComponent = React.createClass({
    render: function() {
      // this.context === {foo: 'a', bar: 'b'} (for the caller above)
      var children = React.withContext({foo: 'c'},() => (
        // In GrandchildComponent#render,
        // this.context === {foo: 'c', bar: 'b'}
        <GrandchildComponent />
      ));
      // this.context === {foo: 'a', bar: 'b'}
    }
  });
Propagate events to parent components when nested

When events are captured, the nearest React-rendered ancestor is found and events are propagated to its tree. This causes issues when components are nested as only the innermost component receives the events.

This change modifies this behaviour so events propagate all the way up the DOM hierarchy. To reduce the performance cost, this DOM traversal is only done if the component is actually nested (determined by the `containerIsNested` map which is lazily initialised).
fixes browserify task transforms support
ignore logs and testing stuff
require coverify
batch logs until the end unless ran with --debug
enable coverage logging from the worker
fixes an issue where the list of files to test isn't complete
speed up server middleware slightly
consoleLoggerMiddleware handles coverage logs
new grunt browserify:withCodeCoverageLogging task
new grunt test:coverage task