ext_proc HTTP/1.1 mode

*Title*: ext_proc HTTP mode

*Description*:
It would be good to support HTTP protocol for ext_proc filter, just like how ext_authz supports both HTTP and gRPC. Sophisticated and performance focused users will find gRPC more attractive while the rest of the lot could benefit greatly from a simpler HTTP API.

We do not need a new HTTP API. What we need is simply a HTTP version of the existing ext_proc gRPC API, with the following caveats to make this system more tenable:
1. Support only request_headers and response_headers. Those who want body should switch to gRPC as its not worthwhile to fiddle with streaming/chunking bodies over http/1.1
2. With just headers, its enough for the HTTP API to be a simple non streamed API call just like the /check ext_authz call.
3. The API is identical to the gRPC one. Calls will be sent to a /ProcessingRequest endpoint. The payload will be a JSON representation of the existing ProcessingRequest proto. The response from the server should be a JSON form of the ProcessingResponse proto. Anything else outside of these bounds can be rejected.
4. We do not need to support bunch of things like mode overrides as they wont make sense in HTTP case. We do not need to support any kind of affinity between the two calls (req_header, resp_header) to the ext_proc server for the same request.

Even with these restrictions, the HTTP version of ext_proc will have quite a bit of utility as users will be able to mutate request/response headers, influence route selection, etc. The async version of this API will bear similarities to request mirroring (sans body).

cc @tyxia @htuch