Possible bugs in MultiRangeInlineEditor

[njx]

Discovered by inspection while fixing #2218. Too risky to fix right now (end of sprint 17) but we should look at them for sprint 18.

1. _updateRelatedContainer() is both attached as a handler for the host editor "change" event and called from _handleChange(), which seems redundant.
2. In _updateRelatedContainer(), the width calculation uses lineSpace.scrollWidth. It seems like this should be either lineSpace.width or this.hostEditor.getScrollerElement().scrollWidth.

[peterflynn]

We could also handle the 2nd issue via #2221, where we'd need to reconcile MultiRangeInlineEditor with the simpler code used in InlineColorEditor.

[njx]

As @peterflynn pointed out elsewhere, it's also not clear why the width calculation needs to be so complicated--it seems like it could just use the scroller's scrollWidth, as we do in InlineColorEditor.

[pthiess]

reviewed and assigned to @njx , sounds like there was potential for refactoring.

[njx]

Turns out (1) isn't a bug...one of them is on the host editor's change event, while the other is on the change event of the inline editor.

[njx]

Turns out there's a reason for the complex width calculation in MultiRangeInlineEditor--the simplistic thing we're doing in InlineColorEditor doesn't work (see #2218). Additionally, if I change lineSpace.scrollWidth to something like $(lineSpace).outerWidth(), it doesn't seem to get the proper width for some reason. So I'm going to close this bug as NAB, do the refactoring in #2221 to port the MRIE calculation up to InlineTextEditor, and comment why the complex calculation seems to be necessary.