Synchronize didOpen and didClose notifications

[vinistock]

Motivation

Closes #1897

In the server / base server refactor, we stopped running didOpen and didClose under a mutex lock, which is not correct.

If we don't run it under a mutex lock, we risk having threads switch and trying to execute a different request before a file has been saved into the Store state, which will then try to find the document in the store, but won't find it.

For files that haven't been saved yet (untitled:Untitled-1 URIs), that will end up trying to read from disk, which is guaranteed to fail since the file wasn't saved.

Implementation

We need to run didOpen and didClose under a mutex lock. We never want the threads to switch during those notifications.

Automated Tests

It's quite hard to write a test for this, so I haven't added one.

Manual Tests

Manually testing is quite easy.

1. Start the LSP on this branch
2. Create an unsaved Ruby file
3. Now, with the unsaved Ruby file selected, restart the LSP
4. Verify it doesn't break

[Earlopain]

The repro seems different for me, I can only get it to (not) work with an extra step, can you check if this PR also fixes this? I still get the error on this branch checked out with the steps below: _{(maybe I'm doing something wrong)}

1. Start the LSP on this branch
2. Create an unsaved Ruby file
3. Switch to a saved Ruby file
4. Now, with the saved Ruby file selected, restart the LSP
5. Verify it doesn't break

[vinistock]

I believe it should fix that scenario as well. Editors will first send a didOpen notification for each file opened in the UI and then fire other feature requests. Since we're running all didOpen notifications under a lock, the server won't be able to switch threads until they are all processed.