[NIO 3.0] Improve our protocol types

[Lukasa]

With Swift 5.7's improved generic and protocol types (specifically with implicit existential unwrapping, primary associated types, and more) we can now begin to unwind some of the awkward decisions that were made in NIO's early stages.

Right now we have a number of types that we explicitly encourage users to hold as existentials. Among these are some of our most important types, Channel and EventLoop. As these types are pervasively used as existentials, we've not been able to add associated types to them in order to reflect their interdependency.

With Swift 5.7 we should be able to lift some of these limitations. In particular, it should now be possible to express that a Channel has a specific associated EventLoop type that matches it. This will allow us to begin to enable generic programming against arbitrary event loops that can create appropriate bootstrap objects as needed.

We can't do this for at least 18 months (we have to drop all the way though 5.6), but we should investigate its feasibility and work out what our APIs would look like if we did this.

[weissi]

Finally! (almost)

[0xTim]

Out of interest - if you're doing a major version bump for this for NIO 3 couldn't you drop any previous Swift versions? E.g. if NIO 3 was released when some hypothetical Swift 5.8 exists, couldn't you support 5.8 only (and then future versions)?

[Lukasa]

Yes, but we don't necessarily want to rush to that.