[aws_c_http_jq] Add aws_c_http_jq fork of aws_c_http recipe

[quinnj]

I have functionality implemented in a fork of aws-c-http that is stalled upstream. The maintainers haven't given a strong signal that they'll even be open to accepting the functionality or continue to maintain the overall server-side support, so I'm proactively forking the library with the idea that one of two scenarios plays out:

1. My contribution remains stalled or even rejected as the maintainers want to remove support for server-side. In this case, HTTP.jl would want to depend on a fork that keeps server-side support, so this fork would be used long-term (we'd continue to merge contributions from the main project in as it applied to client-side).
2. They review, accept, and merge my functionality, and continue to be open to contributions to maintain server-side code; HTTP.jl would then be able to change the planned dependency from aws_c_http_jq_jll to aws_c_http_jll with minimal disruption and this proposed fork would be stale unless needed for other forked functionality in the future.

Release-wise, I'm proposing to start at the 0.9.3 release, which is the latest aws-c-http release, but that also includes my forked contribution. In that way, we could maintain compatibility with upstream releases when they come. If new forked contributions were needed, we could possibly wait until a new upstream release was made, or do an immediate release and maintain an N+M release schedule where this fork would always be M versions (# of fork-only releases) ahead of hte upstream version (N).

I'm open to concerns about this approach and willing to discuss. I'm also just trying to unblock the new HTTP.jl internals-rewrite I've been working on for a while and want to make some progress moving forward. It needs this forked functionality I worked on in an officially published binary, and trying to swap out the existing aws-c-http binary recipe with my fork would seem to have its own set of concerns.

[giordano]

I'm in principle ok with this, my concern is only on whether it's sustainable for you to maintain a fork of a project you aren't (I presume?) exceedingly familiar with but only an end user

[quinnj]

I'm no unconfident I could maintain the fork; I've already fixed a fairly critical memory bug and made a non-trivial contribution on my fork to provide server-side support for websockets. I'm fairly familiar with a lot of the code, but C isn't my strongest language, so it's certainly more effort to make changes there. I anticipate most of the effort required will be bringing in upstream fixes/changes and the occasional HTTP.jl-required change, both of which I feel comfortable with.