Suggest the `initializer_list` overload instead.

3+ args is an arbitrary number that allows for incremental depreciation
without having to update too many call sites.

For more context, see https://github.com/llvm/llvm-project/pull/163117.

Adding support for launching lldb with `-O protocol start MCP` if a
valid ~/.lldb/lldb-mcp-*.json` file is not found.

---------

Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>

This updates MainLoopWindows to support events for reading from a pipe
(both anonymous and named pipes) as well as sockets.

This unifies both handle types using `WSAWaitForMultipleEvents` which
can listen to both sockets and handles for change events.

This should allow us to unify how we handle watching pipes/sockets on
Windows and Posix systems.

We can extend this in the future if we want to support watching other
types, like files or even other events like a process life time.

---------

Co-authored-by: Pavel Labath <pavel@labath.sk>

It's not necessary on posix platforms as of #126935 and it's ignored on
windows as of #138896. For both platforms, we have a better way of
inheriting FDs/HANDLEs.

It creates a pair of connected sockets using the simplest mechanism for
the given platform (TCP on windows, socketpair(2) elsewhere).

Main motivation is to remove the ugly platform-specific code in
ProcessGDBRemote::LaunchAndConnectToDebugserver, but it can also be used
in other places where we need to create a pair of connected sockets.

Use the same scheme as ConnectionFileDescriptor::Connect and use
"listen" and "accept". Addresses feedback from a Pavel in a different PR
[1].

[1] https://github.com/llvm/llvm-project/pull/143628#discussion_r2152225200

The main motivation for this was the inconsistency in handling of
partial reads/writes between the windows and posix implementations
(windows was returning partial reads, posix was trying to fill the
buffer completely). I settle on the windows implementation, as that's
the more common behavior, and the "eager" version can be implemented on
top of that (in most cases, it isn't necessary, since we're writing just
a single byte).

Since this also required auditing the callers to make sure they're
handling partial reads/writes correctly, I used the opportunity to
modernize the function signatures as a forcing function. They now use
the `Timeout` class (basically an `optional<duration>`) to support both
polls (timeout=0) and blocking (timeout=nullopt) operations in a single
function, and use an `Expected` instead of a by-ref result to return the
number of bytes read/written.

As a drive-by, I also fix a problem with the windows implementation
where we were rounding the timeout value down, which meant that calls
could time out slightly sooner than expected.

It's never set to true. Also, using inheritable FDs in a multithreaded
process pretty much guarantees descriptor leaks. It's better to
explicitly pass a specific FD to a specific subprocess, which we already
mostly can do using the ProcessLaunchInfo FileActions.