fix: fall back to stdio when pipe startup fails

[chagong]

Fixes #4433.

This adds a guarded startup fallback for the standard language server: when the initial TransportKind.pipe executable does not connect within the 30-second pipe startup timeout, the extension recreates the client with TransportKind.stdio and starts again. This keeps vscode-java resilient while the underlying vscode-jsonrpc path-budget fix in microsoft/vscode-languageserver-node#1804 is pending/released.

Implementation notes:

• The fallback is limited to executable server options using TransportKind.pipe.
• The fallback only handles pipe startup timeout; non-timeout startup failures still propagate normally.
• The fallback does not attempt to terminate the server process from this layer.
• File rename handlers resolve the current language client lazily so they use the replacement client after fallback.
• Added fake-client tests for pipe rejection, pipe timeout, and stdio failure behavior.

Validation:

• npm run compile passed, with the existing webpack warning from vscode-languageserver-types.
• npm run eslint passed.
• git diff --check passed.
• npm test ran the new Standard Language Client Test; all 3 new fallback tests passed. The full suite still fails on the pre-existing/unrelated command registration assertion where java.getFullyQualifiedName is missing from the actual registered commands in this local run.

[datho7561]

@chagong It seems the fix has been merged in vscode-languageserver-node. Has it been released, and if so, should we prioritize upgrading to work around it? I have a work in progress PR to upgrade the language server client to the latest version.

[datho7561]

I was able to reproduce the bug and can confirm that this patch fixes it. The code looks reasonable, too. Given this is a workaround for a bug that's fixed in a recent language client release, we may want to revert it after we've updated the language client.

Thanks, Changyong!