Implement out-of-proc RAR node lifecycle

[ccastanedaucf]

Context

This implements the node lifecycle for an out-of-proc RAR node via an additional nodemode. This is effectively the minimal implementation for the node server, aka only the setup and connection flow. Next PR will plumb the out-of-proc flag through to the actual RAR task and set up the real pipe client.

Changes Made

3 main parts to this:

• Added RarNodeLauncher to run a single instance of msbuild.exe /nodemode:3 and validate the node connection.
• Added OutOfProcRarNode as the node implementation backed via named pipes. It does not receive or process messages apart from the handshake to validate the connection. The handshake is based on the MSBuild Server handshake implementation, as it avoids baking the process information into the hash.
• Refactored existing code for creating and connecting named pipe client / servers into CommunicationUtilities. This is needed since the RAR node implementation must live in Microsoft.Build.Tasks, and either does not have access to specific types, or runs into compile issues due to duplicated types from Microsoft.Build.Shared once referenced in MSBuild.

Testing

New code is largely IO / glue, so I haven't added new UTs. Let me know if anything sticks out to be tested (will likely need to dep inject in next PRs for testing anyways).

You can validate the server, handshake, and exclusivity are working by setting $env:MSBUILDOUTOFPROCRARNODE=1 and checking tracing logs + active processes.

Notes

• Env var should be replaced by an actual MSBuild flag in the future, but holding off as the feature is still WIP
• Due to potential type duplication, the RAR node implementation will need translation layers between inner types and Microsoft.Build types, and avoid explicitly using node interfaces. For consistency I'm matching function signatures / types as close as possible in case a future refactor can resolve this (see OutOfProcRarNode vs INodeEndpoint, RarNodeShutdownReasonvsNodeEngineShutdownReason`).
• Connection timeouts are temporary, reused from other nodes for simplicity
• Need feedback for consistent naming scheme (e.g. is this the RAR out-of-proc service or RAR node? Should RAR be abbreviated everywhere in the node-related types?)

[JanKrivanek]

Would you be able to separate the pure code moves and actual code changes? It's fine to keep all in a single PR, but separate commits would be great.

It'll help speed up and focus the reviews.

[ccastanedaucf]

FYI I'm separating the code moves (named pipe / IPC stuff) into another PR since I've been further consolidating the IPC code that's duplicated across all node implementations, and that's a bit more risk given the different code paths for the APM and TPL-based versions due to .NET 3.5 compat for the TaskHost. NodeProviderOutOfProcBase, NodeEndpointOutOfProcBase, MSBuildClient, and MSBuildClientPacketPump all use effectively the same logic for setting up the client and server, handshake, sending and receiving packets, serialization, ect., in a way that isn't really reusable via inheritance. Cuts out a pretty big chunk of code from the RAR node implementation too.

Will be updating the main work item with the overall design / ordering of PRs so it helps to see where this is going, since there's still ~5 or so main components after this. But that should be the only real code move / refactoring required for the whole project.