Allow setting InitialWindowSize lower than the protocol default

This is a spinoff of https://github.com/aspnet/KestrelHttpServer/issues/2814. Setting the initial window size to any value larger than the protocol default is easy and was implemented in the first PR. However small servers may want lower values to save memory. Setting the window size to a value lower than the default requires some additional juggling that we weren't prepared for yet.

The root of the problem is that the client is allowed to send frames immediately after opening the connection using the default limits. They don't have to wait for the server's settings frame that may lower the limits. This means the server can't enforce a limit lower than the protocol default until it gets a settings ack.

Proposal:
- Implement the settings ack timeout #2901 to make sure we can eventually enforce the limits.
- Use the protocol default values for the pipe and stream window size initially. See the note about connection windows below.
- Lowering the window size for the connection is trickier. The settings frame only applies to streams, there's no way to send a negative connection window update to the client. We have to start with the default value and then lower it by skipping/shrinking normal window updates that would have restored the window to the original size. At least this isn't dependent on the settings ack.
- When we get the settings ack we can lower the window size for streams accordingly. This may temporarily make them go negative, but that's OK so long as the client doesn't send any more data in the meantime.
- Pipes don't have a way to lower their limits [yet](https://github.com/dotnet/corefx/issues/30689), but that's not required here, it's only a safety mechanism. The flow control window should prevent too much data from being written to the pipe. There's an Assert if we ever hit back pressure from the stream pipes.

Note InitialWindowSize was split into InitialConnectionWindowSize and InitialStreamWindowSize