Add a network port pool concept for allocating discrete service ports

We recently tracked a long running Aspire issue (https://github.com/dotnet/aspire/issues/9919) down to just-in-time ephemeral port conflicts in a specific environment. Effectively in the time between us determining a specific ephemeral port was free and a service launching using that port, some other socket connection on the machine temporarily reserved the port in question. As the port was unused when checking the networking results immediately after the conflict, the likely cause is outgoing network connections as they also consume a port from the ephemeral range.

One option to avoid this issue would be to implement effectively our own internal port pool. We would take a (configurable) range of non-ephemeral ports and identify unused ports in the range to assign to Executables. This would force us to take on some of the work that ephemeral ports provide in identifying an unspecified available port, but the only way we'd encounter a conflict is if another socket on the machine was explicitly assigned the same port in a very short window of time, which is much less likely than an ephemeral port collision.

Main things to work out is performance impacts of searching ports, what would be a reasonable default range, and how we want to allow port ranges to be configured (we at least should support exclusion lists) to avoid conflicts with other services that might need specific ports.

Start by reviewing the linked Aspire issue 9919 and the DCP executable port-allocation entry point. Work out the performance of searching a configurable non-ephemeral range, a reasonable default range, and support for exclusion lists. Done means executables receive ports from the pool while avoiding the stated conflict scenarios.