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.
`{?type}` can by null (which implies it will be handled in some way). `{type=}` mean it can be omitted and give a default value (which basically means "handled in some way").  To me, the difference is that the default value is specified with `{type=}` form.

> `=` means an argument can be omitted and any arguments to the right slide over one space.

That is incorrect. According to [this page](https://developers.google.com/closure/compiler/docs/js-for-compiler):

"Indicates that an argument in a function type is optional. An optional argument can be omitted from the function call. **An optional argument cannot precede a non-optional argument in the argument list**."

(**highlighting** by me)