User experience improvements

[jabraham17]

This PR improves the user experience of this extension by more gracefully handling errors and introducing ways of recovering from those errors

In this PR

• major refactor of the code to be more maintainable and extendable. this refactor enabled all of the following features
• Hides most of the default error popups from vscode, and redirects them to an error log. The it gives the user a nicer error that gives them directions on how to resolve it
• If CHPL_HOME is not set, prompts the user for it
  
  
• If chapel-py is not built, prompts the user to build it (and builds it for them)
  
• add "resolve" setting
• fixes small bug in chapelAst syntax highlighting

[Reviewed by @ShreyasKhandekar]

[mppf]

If Chapel is installed with a prefix installation, there is no need to set CHPL_HOME, but chpl would be in the path.

[jabraham17]

If Chapel is installed with a prefix installation, there is no need to set CHPL_HOME, but chpl would be in the path.

Yes, this PR searches PATH for any chpl executable, and then checks if it can find CHPL_HOME from that (since chplcheck and chpl-language-server both require it). Its mostly a heuristic, as the vscode api does not let me execute code and get back the result (so no chpl --print-chpl-home). See

chapel-vscode/src/ChplPaths.ts

Line 68 in 7f5ddef

export function findPossibleChplHomes(): string[] {

[mppf]

Right, but a --prefix installed isn't laid out that way. For example, chpl might be in /usr/bin and neither /usr nor / are "CHPL_HOME". Of course, this does not need to be fixed right now, especially if chplcheck/chpl-language-server don't work in this mode. Just something to be aware of.

[ShreyasKhandekar]

This looks great to me!

Could you please update the readme so that it tracks the new features? Right now it still asks users to set CHPL_HOME explicitly.