feat: Support stdio transport for GDScript Language Server (LSP)

[MichaelFisher1997]

The current GDScript Language Server (LSP) implementation in Redot is designed to communicate exclusively over TCP (typically on port 6005). While this works well for standard IDE setups, it presents a challenge for modern automation and integration workflows that expect a subprocess-based interaction model.

Most modern Language Server Protocol (LSP) implementations support communication via stdio (Standard Input/Output). Supporting this transport in Redot would simplify integrations for tools that spawn the engine as a background process to perform language intelligence tasks.

Motivation:

1. Unified Tooling: Many editor plugins and automation scripts prefer stdio because it avoids the overhead and potential conflicts of managing local network ports (e.g., "Address already in use").
2. Environment Compatibility: stdio is often more reliable in constrained or virtualized environments (like Docker or Nix shells) where loopback networking might be restricted or require extra configuration.
3. Performance: For local development tools, communicating over standard streams is low-latency and avoids the TCP stack overhead.

Proposed Solution:
Introduce a new command-line flag: --lsp-stdio.

When launched with this flag, the engine should:

• Bypass the TCPServer initialization in GDScriptLanguageProtocol.
• Directly pipe incoming JSON-RPC messages from stdin into the LSP handler.
• Pipe all LSP responses and notifications to stdout.

Technical Implementation Notes:

• The logic would likely involve creating a StreamPeer implementation that wraps stdin/stdout or refactoring GDScriptLanguageProtocol to abstract the transport layer beyond StreamPeerTCP.
• This should ideally work in --headless mode to allow background language processing without a GUI window.

[Arctis-Fireblight]

Seems like an interesting idea. How would you handle other parts of the engine potentially writing to sdtout though?
How would you suggest handling conflicts?

[MichaelFisher1997]

The standard way to handle stdout noise in LSP is to redirect all engine logs (print, push_error, etc.) to stderr. Editors like VS Code already expect this—they pipe stderr to an output window while parsing stdout for the protocol.

We actually have a direct precedent for this in the engine right now. The MCP module calls set_print_to_stdout(false) in main.cpp specifically to keep its JSON-RPC stream pure. Launching with --lsp-stdio would just force this mode and imply --quiet. Since the messages are framed with Content-Length headers, the protocol is also pretty robust against any stray output.