Configure Componets

In looking into implementing a system of the basic components it became obvious that a simpler way to override small details such as labels, image paths and the like was needed. On one hand doing this via `props` does that job, but the code reuse needed to continually configure more or less static attributes opens consumers up to points of failure, especially when those props have defaults and thus work by default, if not as desired. The solution presented in this PR is `React.configClass`.

`React.configClass` takes two arguments.

1. Object returned from React.createClass:
2. Config object:

With these two arguments it clones the `originalSpec` of the provided class and merges the config object into `clonedSpec.config` Doing this means `configClass` treats the passed component as an immutable object, thus letting users configure a base component into a custom one while still using the base as intentionally designed if needed.

## Example

Here is a basic example take from my additions to the Reusable Components docs.

```javascript

var PostLineItem = React.createClass({
  config: {
    typeImage: '/imgs/post-default.jpg'
  },
  render: function(){
    return (
      <li>
        <img src={this.config.typeImage} />
        {this.props.title}
      </li>
    );
  }
}).

var NewsPostLI = React.configClass(PostLineItem, {typeImage: '/imgs/posts-news.jpg'});
var MemePostLI = React.configClass(PostLineItem, {typeImage: '/imgs/post-meme.jpg'});

var PostList = React.createClass({
  render: function(){
    var posts = [];
    for(var i=0; i<this.props.posts.length; i++){
      var postData = this.props.posts[i];
      if(postData.type==='news'){
        posts.push(<NewsPostLI title={postData.title} />);
      }
      else if(postData.type==='meme'){
        posts.push(<MemePostLI title={postData.title} />);
      }
      else{
        posts.push(<PostLineItem title={postData.title} />);
      }
    }

    return (
      <ul>
        {posts}
      </ul>
    );
  }
});
```

## state vs props vs config

* state: mutable instance data
* props: immutable instance data
* config: immutable lifespan data

The biggest problem with this change that I see is that it introduces (or at least seems to introduce) yet another kind of data. That said, if we define state, props and config as I have above, I think its clear that config data has always existed and that while it can be serviced via props (which could be serviced by state) doing so forces code duplication.