Improve .NET SDK error messages when multiple dotnet run instances cause port collisions (Based on next.js feature)

### Is your feature request related to a problem? Please describe.
Running multiple instances of `dotnet run` (or tooling that invokes it, such as AI agents or multiple terminals) often results in port collisions. When this happens, the resulting errors are confusing and not very beginner-friendly, and they don’t clearly explain why startup failed or what is already using the port.

This makes it hard for developers, and especially automated tools, to understand what went wrong and how to fix it.

This request is based on a discussion started [in the parent of this tweet](https://x.com/ChetHusk/status/2019169959713382916) with @davidfowl and @baronfel which highlights port collisions as a common pain point and suggests that better diagnostics could help surface when a collision is likely to occur.

### Describe the solution you'd like
When a port collision occurs (or is likely to occur) during dotnet run, the tooling should surface a clearer, more actionable message.

Examples of improvements could include:

- Clearly stating that another instance of the application (or another process) is already running
- Indicating which port is involved
- Providing guidance on how to resolve the issue (e.g., stop the other process, change the port, etc.)

### Additional context
Other ecosystems have addressed this problem. For example, [Next.js recently added](https://x.com/timneutkens/status/2019023402187575771) clearer diagnostics when multiple next dev processes are running, making it obvious when another instance is already using the dev server.

In parallel, Aspire is exploring solutions in this area. As mentioned by David Fowler in this tweet, upcoming Aspire features aim to reduce clashes by isolating state and randomizing ports for multi-instance scenarios. While this is a great improvement, many projects do not use Aspire yet, so it would still be valuable to consider whether similar diagnostic improvements could be built into the .NET tooling itself for non-Aspire projects as well.