Add new textChange event: input + IE shim

[sophiebits]

IE8 doesn't support oninput and IE9 supports it badly but we can do almost a perfect shim by listening to a handful of different events (focus, blur, propertychange, selectionchange, keyup, keydown).

This always triggers event handlers during the browser's event loop (not later in a setTimeout) and after the value property has been updated.

The only case I know of where this doesn't fire the event immediately is if (in IE8) you modify the input value using JS and then the user does a key repeat, in which case we fire the event on the second keydown.

Test Plan:
Modify ballmer-peak example to add es5-shim and to use onTextChange instead of onInput. In IE8, IE9, and latest Chrome, make sure that the event is fired upon:

• typing normally,
• backspacing,
• forward-deleting,
• cutting,
• pasting,
• context-menu deleting,
• dragging text to reorder characters.

After modifying the example to change .value, make sure that the event is not fired as a result of the changes from JS (even when the input box is focused).

Questions:

• Does it make sense to pass on the native event? Since it could be one of seven different types, I'm not sure that application code would be able to do anything useful with it.
• The propertychange event doesn't bubble so we can't just attach it to document with the other events but is it preferable to have it go through ReactEventTopLevelCallback like the other events even though we're the only ones who'll be interested? Doing so will get rid of the manual enqueueAbstractEvents/processAbstractEventQueue calls I have but I imagine it'll be slower and won't give any other advantages.
• Is the IE9 sniffing code for isInputSupported reasonable? I don't know the preferred way here to handle situations like this.
• IE loses the textarea cursor position when updating the textarea contents during the selectionchange event and having ReactInputSelection attempt to restore the contents doesn't seem to help so I've disabled the event on textarea for now. Ideas?

[zpao]

cc @yungsters

[petehunt]

Please use ExecutionEnvironment.canUseDOM such that this module could be required and not fatal if there is no document symbol in scope. I'm not sure if it'll get required in practice or not, but a good idea nonetheless.

[sophiebits]

Done. (I had canUseDOM originally but lost it somewhere along the way.)

[yungsters]

This check looks good to me.

[yungsters]

Does it make sense to pass on the native event? Since it could be one of seven different types, I'm not sure that application code would be able to do anything useful with it.

Yes, keep passing it along. It's up to the end user to do what they will with it, but I have a new set of "synthetic events" that will allow us to normalize the API for both DOM and custom events like the one you're adding.

[yungsters]

Add a comment about how propertychange does not bubble so we cannot listen to this using top-level event delegation and have to enqueue and process manually. (By the way, @jordow, can you explain why we need two steps for enqueuing and processing instead of one?)