improve perf delaying conversion to immutable objects

[ianstormtaylor]

A few performance tweaks to help ease some of the issues with #791...

Looking in the Performance tab of devtools, we can see that most of the tab is spent in re-rendering the toolbar buttons. Because when the selection changes, they need to recalculate whether they should be "active" or not.

Which (on my machine), when selecting the "large document" amount of text in the "rich text" example is taking 38 seconds. 😱

Most of the time is spent re-rendering the mark buttons...

But there is also a decent chunk spent recalculating the block buttons...

All in all the largest amount of time is spent in...

78.2% RichText.renderToolbar()
    64.5% RichText.renderMarkButton()
        60.8% RichText.hasMark()
            60.8% getMarksAtRange()
                60.5% getCharactersAtRange()
                    60.5% reduce()
                        59.2% concat()
                            -> Immutable.js internals
    13.6% RichText.renderBlockButton()
        12.9% RichText.hasBlock()
            12.8% getBlocksAtRange()
                9.8% getClosestBlock()
                    9.6% getAncestors()
                        3.6% hasChild()
                            2.0% getChild()
                3.0% toOrderedSet()
                    -> Immutable.js internals

This PR changes the way lots of the get* and get*AtRange methods work to delay converting to Immutable.js objects until after iterating, since it's a lot faster to use .map, .filter, etc. with regular arrays when possible than with immutable objects.

After all of the changes, the benchmarks show a pretty decent increase for many things...

And now re-running the same performance analysis shows that the total time for the same re-rendering is now ~8 seconds instead of 38. And now the biggest time sink is actually in the block buttons, because the mark buttons have been significantly sped up...

Still more work to be done, but a pretty big win for very little work.