Decouple the Kestrel transport layer from Microsoft.AspNetCore.Hosting

[davidfowl]

Both Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets and Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv depend on Microsoft.AspNetCore.Hosting because they expose extension methods on IWebHostBuilder, with the move to generic host and exposing the ability to create client connections from these transports (#10872), it's odd to have this dependency.

It seems like to preserve UseSockets and UseLibuv, we'll need to have extensions methods like these somewhere, either on the IWebHostBuilder or on the IServiceCollection. It seems like we'll need to introduce new packages to that have just the code without the extensions and another one that has the wire up code (much like we have the kestrel meta package today).

cc @shirhatti @anurse

[analogrelay]

Feels post-3.0 based on your description :). But sounds like goodness

[analogrelay]

Work in 3.0:

• Make sure the only public things in the transport packages are the extension methods. OR any public types are in the expected final namespace so they can be Type Forwarded.

Post 3.0:

• New Packages: Microsoft.AspNetCore[?].Transports.[Sockets/Libuv] with extension methods that hang off IServiceCollection
• Keep the old packages as back-compat for the IWebHostBuilder extension methods.

[analogrelay]

This feels super at risk for 3.0.

[analogrelay]

If we don't take it in 3.0, the next main place is 5.0 which isn't LTS anyway so it's perfect to do a major reshuffle like this.

[analogrelay]

It's too late, among the other things, to try and squeeze this in. It sounds like a good fit for 5.0 though.