Investigate self-hosting Neva developer tools

[emil14]

Goal

Determine what is required to implement developer tools in Neva itself, starting with a possible future neva-lsp rewrite.

Why

Today neva-lsp is written in Go. Reimplementing it in Neva would be a meaningful real-world validation of the language, but it must not block the current VS Code daily-driver or LSP distribution milestones.

Exploration map

• inventory runtime and standard-library capabilities needed by an LSP server: stdio, JSON-RPC framing, filesystem watching, process lifecycle, concurrency, network/HTTP where required;
• identify compiler/indexer APIs that must become public and stable;
• prototype a minimal stdio JSON-RPC server in Neva;
• define a parity test suite against the existing Go LSP;
• decide whether a full rewrite is feasible or whether only selected tools should be self-hosted first.

Non-goals

• no rewrite in this issue;
• do not delay lsp/v0.1.3, neva tool, or vscode-neva#28.