Improve systemd socket activation endpoint handling in Kestrel

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

## Problem
When using systemd socket activation with Kestrel, if an application has endpoints configured (e.g., in `appsettings.json`) that match the systemd-activated sockets, Kestrel attempts to bind to these endpoints again. This results in "Address already in use" exceptions, even though these sockets are already being handled by systemd.

Current workarounds require developers to either:
1. Remove matching endpoint configurations entirely
2. Use reflection to clear endpoints (unsafe)
3. Use P/Invoke to detect socket paths (platform-specific)

## Impact
This affects any ASP.NET Core application using systemd socket activation, particularly those:
- Transitioning from direct socket binding to systemd socket activation
- Maintaining configurations for different deployment scenarios
- Using configuration management systems that may not be aware of systemd socket activation

## Example Scenario
```csharp
// appsettings.json
{
"Kestrel": {
"Endpoints": {
"Unix": {
"Url": "http://unix:/srv/socks/myapp.sock"
}
}
}
}

// Program.cs
builder.WebHost.ConfigureKestrel(options => {
options.UseSystemd(); // Will conflict with appsettings.json endpoint
});
```

When run under systemd socket activation:
```
Unhandled exception. System.IO.IOException: Failed to bind to address http://unix:/srv/socks/myapp.sock: address already in use
```

## Questions
1. Should this be handled automatically by `UseSystemd()`?
2. What level of logging/warning is appropriate when endpoints are disabled?
3. Should there be a way to opt out of this behavior?

I'm happy to work on a PR for this once we agree on the approach. I have some implementation ideas in mind and have checked the underlying socket handling code.

### Describe the solution you'd like

## Proposed Solution
Enhance the existing API with:
1. Detect systemd-activated socket paths using `getsockname()`
2. Automatically disable any configured endpoints that match these paths
3. Log appropriate warning messages about disabled endpoints

Example API:
```csharp
// Enhance existing UseSystemd()
options.UseSystemd(cleanupEndpoints: true); // Now handles conflicts automatically

// Or add new method
options.UseSystemdWithEndpointCleanup();
```

## Alternative Approaches Considered
1. Manual endpoint cleanup - Less robust, more error-prone
2. Ignore bind errors - Makes debugging harder
3. Add configuration option to disable endpoints - More complex for users

### Additional context

This was discovered while implementing a security improvement (switching from TCP to Unix domain sockets) in an ASP.NET Core application. The current behavior forces developers to choose between configuration flexibility and socket activation support.