Formatter and tests depend on VS Code behavior

[mark-wiemer]

Currently we have one big function, provideDocumentFormattingEdits, that accepts a vscode.TextDocument and returns a vscode.TextEdit[]. Our tests are fully end-to-end, which sounds good at first: We open a file, have VS Code format it using our extension, and then test the file contents against an expected file.

However, if there is some issue with VS Code itself and not our app, these tests will fail.

Instead, we should separate responsibilities a bit:

1. Outer function that accepts vscode.TextDocument, etc., and gets necessary config values.
2. Helper function that transforms vscode.TextDocument into a string
3. Inner function that accepts a stringified document and returns a stringified document. This is the core formatter algorithm and will be much easier to test with standard string variables instead of vscode.TextDocument and vscode.TextEdit values.
4. Helper function that transforms (in: string, out: string): vscode.TextEdit[] to send back to VS Code

With this, we will only have to test the inner function thoroughly. It will be easier to test because we won't have to go through the VS Code API every time.

We should still have a few end-to-end tests for larger functions, but we don't need it for each one.

This will make tests run faster and it should make it easier to isolate our core logic from the VS Code API, making tests easier in the future. This will also serve as a good reference point for loose coupling in this project.