Use DocData for reading/writing launchSettings.json

## Summary

Currently when we read or write launch settings through the `LaunchSettingsProvider` type we go straight to the file on disk. We should instead go through a VS `DocData` with the file contents loaded into memory.

## User Impact

The current approach has a couple of limitations when the user opens the launchSettings.json for editing:

- Changes to the launchSettings.json will not show up in the launch profiles and related data structures until the file has been saved, the `LaunchSettingsProvider` notices that it has changed on disk, and it has had a chance to reload the data from the file.
- If there are pending changes in the file when the user runs the project (via F5/Ctrl+F5) the file will be saved, but the changes are not likely to be picked up for the run. This is because we are likely to build and run the project before we notice/process the changes on disk.
- If the user makes changes directly to the file but does not save, then edits the profiles through the Launch Settings UI, their manual edits will be overwritten. This is because we have no knowledge of the pending changes when the UI persists the data back to the file on disk.

## Implementation Notes

Ideally we wouldn't be the ones loading the file into a `DocData`. Instead we should use the file on disk as the "source of truth" until the user opens the file in the editor, and then we would switch to using the `DocData` as the source of truth. If the user closes the editor and the `DocData` is removed from the running document table then we would go back to using the file contents on disk.

When the user is manually editing the file we would ideally "promote" the contents to a new set of launch settings whenever the file text is valid JSON that we can successfully deserialize into our data model, _and_ whenever the user saves--even if they save a broken file that we can't deserialize and they effectively end up with no settings.