hh_server needn't sort autocomplete results when IDE will do it instead

hh_server needn't sort autocomplete results when IDE will do it instead

Summary:
Long story short, (1) there's no need for hh_server to sort its autocomplete suggestions when connected to an IDE since the IDE will use its own sort, (2) if hh_server isn't sorting, then it needn't bother computing its `expected_ty` field.

Previously, autocompleteService.ml was sorting its results -- if doing autocomplete inside a function argument position then it prioritized completions whose return type matched the parameter type, and apart from that it sorted alphabetically.

The previous Nuclide persistent connection ignored that sort order. It instead used a sort order primarily geared towards getting a good result for partial matches, e.g. when you type `$this->con|` then it preferred the autocomplete options that matched the letters `c` and `o` and `n` -- preferring them together, preferring them in that capitalization, and so on. This is implemented in autocomplete.js::compareHackCompletions. Although implemented in the Hack package, there's nothing Hack specific about it - it's just a general purpose algorithm to prefer certain kinds of typeahead matches.

Flow actually uses a different typeahead filter sorting algorithm. It just uses the off-the-shelf package fuzzaldrin-plus.

(AutocompletePlus itself also uses fuzzaldrin-plus, but as far as I can tell that's only used for the default SymbolProvider; when you write your own provider you're expected to sort yourself).

Anyway, I'm removing sorting from hh_server in these cases where it's not needed. (Partly because we'll have to implement LSP-specific sorting algorithms and it's confusing things when Hack does its own sort; partly because autocomplete is taking 400ms for a 1000+ member class which is rather too long and I wonder if this is a culprit.)

Reviewed By: dabek

Differential Revision: D5376780

fbshipit-source-id: 32ec344afb03295584b8565119b098fdc8b99646