Merge Kestrel.Https into Kestrel.Core

[Tratcher]

This is being done because #2186 is trying to make Https first class, but the assembly separation is causing some awkward design problems.

Type forwards have been included to mitigate potential breaks.

This also fixes the sample app.

[halter73]

Assuming it builds ofc.

[davidfowl]

We’ll have to figure out how this affects bedrock. The more I think about it. The more it might just make sense to make a new sever and set of APIs

[halter73]

@davidfowl We can still use the bedrock abstractions for HTTPS even if it's shipped in one assembly. We only want the assemblies merged to make the default-on HTTPS scenario better in Kestrel.

I don't expect any other connection middleware has the same requirements. If we weren't trying to do the following, I wouldn't merge the two assemblies:

1. Skipping the application of the default HTTPS adapter only when one hasn't already been applied to a given endpoint. The IsHttps addition to IConnectionAdapter is a clear sign that the HTTPS is indeed a very special case.

   Right now we check IsHttps in the Core assembly, but this might be less of an issue if the UseHttps extension method is changed to examine the existing ConnectionAdapters and throw whenever an HTTPS adapter has already been added. If we did this though, it could cause issues for people trying to reconfigure the default HTTPS endpoint using ConfigureHttpsDefaults.

2. Allowing the developer to specify a configuration callback using ConfigureHttpsDefaults that runs for the default HTTPS endpoint any any HTTPS endpoints defined afterwards even if the endpoint is defined using the legacy UseHttps() API which is just a static extension method on Kestrel.Core.ListenOptions and therefore does not have a real way to access the default HTTPS configuration unless it's referenced by ListenOptions.

If it weren't for these two issues, I think I would be fine with keeping the assemblies separated. Maybe @Tratcher has more reasons to keep them merged though.