Further editor fanciness

Features

[x] Code folding: This should be pretty easy - just walk over any "large" definitions and offer to fold them to a single line.
[ ] Type at cursor/Type tooltip.
[ ] Completion
[ ] Document highlight: This should just be composed of "find this symbol" and then "walk the entire resolved tree".
[ ] Go to definition: The nicest approach to this might be to augment names with the position at which they were defined.
[ ] Explain error at point:

This will either involve embedding the explanation information within the language server, or shelling out to "amc explain". Note, this will require explicit support within the editor.
[ ] Editor-specific support for code lens: F♯/Ionide has custom handling for type-signature overlays, which renders the signature to the side (taking up less vertical space and looking nicer). If the editor doesn't support this extension, it gracefully falls back to normal code lenses.
[ ] Workspace symbol: We'd need to parse every file in the project root, and then gather all symbols defined in them.

One thing to be aware of is the complexities in mapping locations back to the typed AST. Typing and desugaring introduces additional nodes, so we need to be careful that what we point to is the correct definition.

Minor cleanup

[x] Split the code lens functionality into provider and resolver. This should also fix problems with showing signatures on classes/instances.
[x] Add a configuration option to disable "type signature code lens" support.
[ ] Improve reporting of erroring imports. Ideally we'd give some hint on why an import failed.
[ ] Add some input debouncing. This should be disabled by default, and configured by the client.
[x] Write tests for everything.

Further notes

The compiler is currently very much structured in a fail fast manner. Resolution (and TC to a lesser extent) either succeed, or fail and throw away all information. This is obviously not ideal as far as editing goes, as you are rarely operating on a well-formed tree.

There's a couple of things we could do to improve this:

Make parsing more fault-tolerant. It's really not clear how to do this using Happy, and I don't really fancy home-growing another parser generator. There's some interesting notes in this document, which basically distils what things like Roslyn.
Resolution could definitely return an unresolved tree - we already do something similar with junkVar. If we were really fancy, we could even parse such a tree off to TC, and make it smart enough to skip unresolved nodes.
Some operations can operate on older versions of the tree - we just need a function to map positions between old and current locations.
Some elements of verification could be done earlier (foreign parse errors only needs the parsed tree, unused variables could be done within resolve).

amuletml / amulet