BeforeInput is fired with a wrong text at a wrong time on IE

[msmania]

This patch addresses a typing issue with Japanese IME on Internet Explorer.
The issue is related to the known issue about Korean IME documented in draft.js,
but different. Korean issue is not addressed by this patch.
This patch also adds a new testcase to cover BeforeInputEventPlugin.

Repro steps:

1. Open IE11 and navigate to https://facebook.github.io/draft-js/
2. Turn on Japanese IME and type Japanese text on the 'Tell a story' box

Issue description:

The 1st candaidate is always committed even when we try to commit the 2nd
or later candidate. Since facebook.com is using draft.js, this issue can
be reproed on the NewsFeed Post box of facebook.com.

Root cause/Fix:

React creates a browser-independent beforeInput event to match W3C spec
from the combination of the existing events (e.g. compositionstart, keyup,
textnput, and etc.). The problem is that in IE, onBeforeInput is fired with
a wrong text at a wrong time.

Basically React uses textInput events to create beforeInput. However, IE
fires an event named textinput (all lowercases), that is not useful due to
a couple of IE's incorrect behaviors as below.

1. With Japanese IME, after one or more implicit commits, when a user ends
   composition, a textinput is fired, but it contains only the last composition
   text.
2. With Japanese IME, a textinput event does not contain an ideographic
   character (U+3000) when a user hits a space key not in composition state.

As a fallback, React stores a text of a target element at compositionend or
additional keyboard/mouse events, and fires beforeinput at compositionend
with the stored text. One of the additional events is keyUp with keyCode=32.

With Korean and Chinese IME, a space key is one of keys to end composition.
With Japanese IME, however, a space key does not mean the end of composition
but just switching candidates. As a result, the first candidate is stored as
a fallback text, and it is displayed even if a user selects the 2nd or
a subsequent candidate.

The fix is that we don't use additional keyboard/mouse events if composition
event is available. IE9-11 fires composition events even though its event data
is not correct. It's good enough to use as a time to store a fallback text.

[gaearon]

@hellendag Is this something you could look into?

[sophiebits]

@msmania Do you mind rebasing this? Otherwise I think this is okay to go in.

[msmania]

Thank you for looking at this, @spicyj . Rebase is done. I also removed topLevelTypes from the test code.

[sophiebits]

Thank you!