Better fix for file browser race condition

[Charles-Gagnon]

With further testing I found I was still occasionally hitting the error in #23832

Dug into it more and found out that while the order the messages was being sent in was now correct, the STS code still has async issues.

Here is the handler for the open request : https://github.com/microsoft/sqltoolsservice/blob/main/src/Microsoft.SqlTools.ServiceLayer/FileBrowser/FileBrowserService.cs#L96

Notice that we kick off the task but then immediately return true - which then allows the follow message to start processing. Normally the order would be expected to be this :

1. Open message received with no change filter (initialize)
2. Create FileBrowserOperation here : https://github.com/microsoft/sqltoolsservice/blob/main/src/Microsoft.SqlTools.ServiceLayer/FileBrowser/FileBrowserService.cs#L236 and store it
3. Complete initialization
4. Get second open message with change filter
5. Look up previous FileBrowserOperation
6. Apply filter and return

But because we weren't awaiting the first one to finish this is what happened

1. Open message received with no change filter (initialize)
2. Kick off Operation and return true
3. Start processing second open message with change filter
4. While initial open message is creating the operation, the second one tries to look up the operation and can't find it, so fails
5. Return succeeded = false and display error

The STS code isn't great, but in this case I found an even better solution was to remove the unnecessary second open message (with changeFilter) from even happening. This means that on launch of the dialog we only ever send the initialize message anyways and so there's no chance of any error happening. Passing in the item to select directly into setOptions skips the logic to send the "selection changed" event and so we never send that second message. This not only fixes the issue, but also improves performance since we don't have to redraw the tree for the second message.

[Charles-Gagnon]

Fully verified this time with private RC1 build and no longer see the error, and that only one open message is sent