[Docs] document optional param for renderComponentToString
update version for 0.10rc
0.10rc blog post
Fix a minor typo in the `update()` docs
Merge pull request #1273 from wincent/typo-fix-02

Fix a minor typo in the `update()` docs
Upgrade Commoner to v0.9.2 to silence deprecation warnings.

Closes #1278.
Merge pull request #1186 from chenglou/doc-toString-opt

[Docs] document optional param for renderComponentToString
add CodeWinds episode 4 w/Pete Hunt to videos

Added to videos.md
Merge pull request #1282 from jeffbski/addCodewinds004Videos

add CodeWinds episode 4 w/Pete Hunt to videos
Update AUTHORS for 0.10
0.10 release materials
version bump for 0.11 development
Add client/server mention in componentDid/WillMount documentation
Rename objMap to mapObject

mapObject fits better with other module names ("flattenChildren", "traverseAllChildren" etc.) and highlights that it only works with objects - which is going to be more important once we'll have an ES6 Map polyfill.
Remove objMapKeyVal
TextInputEventPlugin, SyntheticTextInputEvent

This diff introduces `TextInputEventPlugin` and `SyntheticTextInputEvent`, which are based on Webkit's native `textInput` event.

In Chrome, Safari, and Opera, the `textInput` event fires prior to the insertion of character data into the document. For normal typing, for example, thevent sequence is: `keydown`, `keypress`, `textInput`, `input`, `keyup`. The `textInput` event contains a `data` field corresponding to the character data that will actually be inserted.

There is also a `beforeinput` event described by http://www.w3.org/TR/DOM-Level-3-Events/#event-type-beforeinput, and this is essentially that event, so it may make sense to rename the plugin.

This event is especially useful because it solves a number of issues we can't currently handle with only keypress and composition events:

  - **Windows Chrome: Trailing characters discarded in Korean IME.** For instance, `안녕하세요` becomes `안녕하세` with the final character discarded by the final `compositionend` event. The `textInput` event fires correctly with the final character.
  - **Windows Chrome: Special characters discarded in IME.** Certain ideographs are discarded in IME mode. In Japanese, typing the ideographic space character is not represented by keypress but //is// represented by the subsequent `textInput`. This issue also applies to punctuation characters in Chinese.
  - **OSX Chrome: Characters from palette discarded.** Inserting characters from the OSX character palette fails, since no keypress is fired.

The plugin is useful for Firefox and IE. For these, we record inserted characters via keypress and compositionend events and dispatch the synthetic event with these characters as the `data` field to match the native `textInput` event.

  - Firefox has no corresponding `textInput` event and has not yet implemented `beforeinput`.
  - IE has a native `textinput` event, but it fires after the DOM mutation has already occurred, so it isn't very useful as an analog to the Webkit version. I'm just not going to bother with it.
assertValidProps for updating DOM components through renderComponent

`renderComponent(<div style={invalidType}/>, container)` throws correctly,
but not when it's called a second time (i.e. updating rather than mounting).
It goes through `ReactDOMComponent.updateComponent` but there wasn't a
props assertion there.
(Removed the assertion in `receiveComponent`)
Remove last uses of {' '} in docs and tests

Whitespace fix is in, so no need for {' '} anymore.
Repair spacebar textInput

Browsers that natively support the `textInput` event appear to have a bug: when preventing default behavior for a `textInput` event occurring for a spacebar keypress, the character is prevented from being inserted **but the browser scrolls down**.

Minimal repro example: http://jsfiddle.net/salier/bX4fw/

This is ridiculous, since scrolling makes no sense when the user is focused in a textinput or contenteditable. Preventing default at the `textInput` stage should mean to prevent the character from being inserted, and should have no impact at all on scrolling behavior. I have filed this as a Chromium bug (https://code.google.com/p/chromium/issues/detail?id=355103) but I'm not going to hold out much hope that they'll fix it.

To resolve this, I'm special-casing the spacebar character at the plugin level, in `BeforeInputEventPlugin`. I looked for ways to do this at the component level, but it seems to me that this is simply a browser bug and it's cleaner to handle it there.

In browsers that can use the native `textInput` event, I'm checking the code of the pressed key. If it's the spacebar, we dispatch the synthetic event as if there were no native `textInput` event -- as if we were running Firefox. Then, if the synthetic event is not canceled and we make it through to the native `textInput` event, bail if the character data is a space character.
Fix docstring arg order in createDOMComponentClass