Quick Edit result grouping

* Group Quick Edit results into collapsible sections by file.  Collapsed sections are remembered per project as view state.
    * Also simplifies the rule list UI code in MultiRangeInlineEditor: we now simply re-render the whole list when items are added/removed, instead of trying to update it incrementally.  Also removes unneeded async code in `_updateSelectedMarker()`, unused arg in `sizeInlineWidgetToContents()`, and a few other smaller things.

* The initially selected result is now the first _non-collapsed_ result; if all results are collapsed, an explanation is shown in the editor area.  One exception: if there's only one result it's always selected even if collapsed, since the rule list is hidden when there's only one result, leaving no way to expand the collapsed section.

* Consistently sort Quick Edit results (previously, their order was nondeterministic -- the cause of some intermittent unit test failures!).  By default, MRIE sorts in the same order as Find in Files.  In CSS Quick Edit, there's extra logic to bubble up all LESS/SCSS files to the top of the list.
    * This PR **changes the Find in Files sort order** - on master, files with deeper nesting are listed before shallower files with the same path prefix (e.g. `/project/folder/subfolder/foo.js` comes before `/project/folder/bar.js`)... and thus any files at the project root are always listed last.  This PR reverses that: shallower items are listed higher, and thus any files at the project root are always listed first.
    * This also changes the sort order of the New Rule dropdown to be consistent with the Quick Edit order.  Previously, files were sorted primarily on filename (files with the same name in very different folders appeared next to each other in the list).  Now it uses the 'standard sort order' shared with Find in Files, sorting primarily on folder (files in the same folder appear next to each other in the list, regardless of filename).  Duplicate filenames still display extra path snippets to disambiguate them in the dropdown.
Interesting.  There's _some_ ambiguity there because it doesn't say whether it's talking about formal vs. actual parameters, but I think your interpretation is most likely correct.  That disagrees with how some of our existing code uses (e.g. all of FileSystem), but since that usage now seems incorrect I'll change it to `=` here.