Add structured concurrency aware ServerBootstrap bind

[fabianfett]

This is a very early draft of a structured concurrency aware ServerBootstrap bind method.

[fabianfett]

Currently open questions:

1. How do we want to deal with 6.0 not supporting sending correctly? Gate this feature behind 6.1+? Given that we intro it as SPI, we might be able to wait until we drop support for 6.0.
2. executeThenClose has a lot of tests. (> 2000loc). Do we want to duplicate those tests for the new methods?

@Lukasa @FranzBusch wdyt?

[FranzBusch]

1. How do we want to deal with 6.0 not supporting sending correctly? Gate this feature behind 6.1+? Given that we intro it as SPI, we might be able to wait until we drop support for 6.0.

I would actually propose just putting it behind 6.2 since we best leverage the nonisolated(nonsending) spelling here as much as possible for both correctness around the return parameter and performance.

2. executeThenClose has a lot of tests. (> 2000loc). Do we want to duplicate those tests for the new methods? One reason for the many tests is that we have to test all the different bind/connect methods. With the new BindTarget I hope we can reduce this drastically by creating one generic test method and then just call that with different bind targets.

[fabianfett]

Not sure I agree here:

With the new BindTarget I hope we can reduce this drastically by creating one generic test method and then just call that with different bind targets.

We would still need to test all options. We might be able to reduce the number of lines with Swift Testing, but the main question still stands.

[FranzBusch]

We would still need to test all options. We might be able to reduce the number of lines with Swift Testing, but the main question still stands.

I personally think we need to test it all. If you can avoid duplication then that would be great but if we can't then we need to duplicate.