Background: we maintain the Go language server (gopls). This server is both an LSP server and an integrated web server. The web server provides documentation, reports, profiles, forms, and other graphical query responses that don't easily fit into an existing LSP response. Some links in these web documents are references to source file locations. Clicking on such links causes the browser to send a request to the web server; but instead of navigating the browser to that location, the server sends an LSP showDocument downcall to the client editor, causing the editor to navigate to that location. In this manner, the client editor and the browser can ping-pong back and forward between each other, providing a richly integrated yet editor-portable user experience.

However, in the VS Code implementation of the LSP showDocument request, if the browser window is on top of the VS Code window, the editor moves its cursor and takes focus, but does not raise the window. This can make it hard to tell to the user clicking in the browser that anything happened at all. The solution is for the LSP showDocument request to raise the window (and to document this behavioral requirement). This could be done in one of several ways, including:

1. Unconditionally raising the window when the LSP showDocument request specifies external=false and takeFocus=true. This is the simplest approach and my favored one, but perhaps raising the window is not always desirable.
2. Adding yet another boolean field to to the LSP showDocument request indicating that the window should be raised.
3. Raising the window only when a showDocument request is received asynchronously; that is, not during an active client-to-server LSP call initiated by a user interaction, which would imply that the editor window is already visible.

Whichever approach is decided for the LSP integration, VS Code needs to provide a function to raise the editor window. Therefore:

Proposal: we add a function, raiseWindow, that raises the current editor window.

Related: #207634