TextArea.select() has always been supported in IE

since before the beginning of time, according to http://help.dottoro.com/ljwbxutr.php

which actually means since version 3.0, according to http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(Document_Object_Model)#HTML
comment setTextareaSelection guard on keypress
fix #71, check if selection in textInput()

Turns out the skipTextInput guard in copy never
fully worked, there's an edge case where
textInput() happens after the Ctrl+C keypress
but before the copy event could set the
skipTextInput guard, so it would see the selected
text in the textarea and, thinking that text was
typed by the Ctrl+C keypress, input it character-
by-character into MathQuill.

The right thing to do, then, is instead of a guard
flag, check if there is a nonempty selection in
the textarea. There couldn't possibly be selected
text in the textarea if some new text was just
typed in, because the selected text would be
replaced by the typed text and the cursor would be
after the typed text.

There is a dearth of compatibility tables for
selection APIs, but according to Dottoro
selectionStart/End is supported by IE 9 and other
modern browsers: 
http://help.dottoro.com/ljtfkhio.php

As far as I can tell, IE's proprietary
document.selection et al are supported by at least
IE 6+. It has no direct way to find the start nor
end of the current selection like you can the
standardized way, the way this works is if
document.selection.type is anything but 'Text',
then there is no selection or it's of HTML, not
text in a textarea. If it is 'Text', the
selected textarea still may not be this MathQuill
textbox's hidden textarea. I disregard the
possibility that document.selection.createRange is
truthy but it's not IE's API, that possibility
*deserves* to blow up and throw an exception.

References:
- document.selection
  http://help.dottoro.com/ljefwsqm.php
  http://msdn.microsoft.com/en-us/library/ms535869(VS.85).aspx
- selection.type
  http://help.dottoro.com/ljitmswc.php
  http://msdn.microsoft.com/en-us/library/ms534692(VS.85).aspx
- selection.createRange()
  http://help.dottoro.com/ljrvjsfe.php
  http://msdn.microsoft.com/en-us/library/ms536394(VS.85).aspx
if selection.type === 'Text', then
selection.createRange() returns a
- TextRange
  http://help.dottoro.com/ljgbbkjf.php
  http://msdn.microsoft.com/en-us/library/ms535872(VS.85).aspx
on which you can call
- range.parentElement()
  http://help.dottoro.com/ljcfdmjx.php
  http://msdn.microsoft.com/en-us/library/ms536654(VS.85).aspx
in IE on textInput don't need to check selection

according to http://unixpapa.com/js/key.html (and
my own testing), IE doesn't trigger keypress (and
hence the fake textInput) when you press
Ctrl+X/C/V, so this part of b1318e5 should be
unnecessary.

If anything like #40 or #71 is reported in IE <9,
revert this and include the research from b1318e5.
pasting => skipTextInput

instead of vague skipTextInput, with the better
guard in b1318e5 against mistaking a selection
for typed text, now only need a guard for the one
edge case of textInput() happening in between the
paste event firing and paste() dealing with the
pasted text. Rewire where the guard flag is set
and unset to match