Add support for server-side websocket upgrade

[quinnj]

The main idea here is a new aws_websocket_upgrade function that allows creating an aws_websocket instance from a server-side stream. In order for the stream to correctly be marked as having switched protocols in s_stream_complete, I added a is_switching_protocols bool field to the aws_h1_encoder_message struct that is checked in s_stream_complete.

Usage would then allow calling aws_websocket_upgrade from the server-side on_complete function of aws_http_request_handler_options and using the aws_websocket instance as desired as a server websocket.

I recognize that there may be a cleaner or more desirable way to track the is_switching_protocols, but after playing around with a few things, this approach seemed pretty simple. If we'd prefer to track this on the aws_h1_stream instead, or in some other way, I'm open to ideas.

I'm also open to other approaches on how to handle/allow the overall aws_websocket_upgrade. The other thought I had was perhaps you could pass something like the proposed aws_websocket_server_upgrade_options to the server configuration options itself and then aws_websocket_upgrade would be called automatically if an incoming websocket upgrade request was detected? i.e. teh websocket response would automatically be sent, the websocket upgraded, and then two aws_websocket_on_connect and aws_websocket_on_connect_shutdown callback functions would be required? That seemed a little more involved and I wasn't sure if it would even work dependency wise with server bringing in websocket definitions.

I also realize a discussion/issue could have been opened around this, but I've also just been personally curious to dive in and try something out in the project and this has been a fun way to get to know all the http (h1 at least) lifecycle code. Happy to restart if there are ideas on how to do something like this cleaner/simpler starting from scratch.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[quinnj]

(motivation-wise, this is one of the last pieces of functionality we are hoping to support to have the Julia HTTP.jl package be able to replace it's internal implementation with aws-c-http functionality: JuliaWeb/HTTP.jl#1213)

[quinnj]

(also, obviously additional documentation and tests can/would be added depending on how initial reviews of the proposed code go)

[quinnj]

Bump @graebm for review/thoughts

[quinnj]

Bump @TingDaoK / @DmitriyMusatkin ?

[TingDaoK]

like what we mentioned before, here. The server-side features will not be prioritized by the team.
I think the best option for you to move forward is probably maintain your fork for the server side functionalities, if possible.

I can try to take a look, but I will also need to read through the spec to have better understanding and to balance between other projects we are planning to work on.