* calculate project root via location of .wasp file
previously, waspls used workspace root, which was incorrect if you opened a
workspace larger than the wasp project.
this does not add support for multi-project workspaces.
* update changelog with waspls scaffolding info
* create directories when scaffolding, if needed
* refresh export cache after scaffolding
* better process for ensuring a blank line between old code and new scaffolded code
Previously, waspls incorrectly thought that importing `@client/file.jsx` could be referencing the file `src/client/file.tsx`. But this JS/TS "merging" is only correct on the server (for reasons that are not explained by the TS documentation on module resolution). This commit fixes that by requiring exact matches for external imports beginning with `@client`.
This incorrect behavior manifested as several different bugs:
- Not reporting missing `.jsx` files when a `.tsx` file with the same name exists.
- Go-to definition going to the `.tsx` file instead of the `.jsx` file when the external import ends in `.jsx`.
- Scaffold actions suggestions scaffolding in both the `.jsx` and `.tsx`files.
This commit fixes all of these buggy behaviors.
When an external import tries to import a symbol from a TypeScript/JavaScript file, waspls now offers quickfix code actions to scaffold a function in that file.
It uses the surrounding context of the external import to determine what code to write for the code action. See [`ScaffoldTsSymbol.hs`](457911d5e9/waspc/waspls/src/Wasp/LSP/Commands/ScaffoldTsSymbol.hs) for a detailed description of how it works. At a high level, there is a `templateForFile` function in `Wasp.LSP.Commands.ScaffoldTsSymbol` that selects the correct template from `data/lsp/templates/ts`. For example, `action.fn.ts` contains a template for scaffolding an `action` function in a TypeScript file and would be used when a code action is requested with the cursor at the location marked by `|`:
```wasp
action createTask {
fn: import { createTask } from "@server/actions.js"|
}
```
The scaffold action runs as a [LSP command](https://microsoft.github.io/language-server-protocol/specifications/specification-3-16/#workspace_executeCommand). To prepare for wanting to define more commands in waspls in the future, this PR also introduces the concept of `Commands` (`Wasp.LSP.Commands.Command`) that define some properties about each command waspls wants to handle.
