Remove Concept of Multiple Protocols within HTTP

[grant]

Expected

We by default use the HTTP protocol for CloudEvents.
We do not need to specify if the CloudEvent module accepts only binary or only structured events.

Actual

We specify the protocol in the Receiver constructor. Not sure why.
Seems overly complicated.

https://github.com/cloudevents/sdk-javascript/blob/master/src/transport/receiver.ts#L40
https://github.com/cloudevents/sdk-javascript/blob/master/src/transport/protocols.ts

[grant]

I would assume the Receiver to only have static methods in the first place and not be an object.

Why would an application want to have to manage multiple CloudEvent receivers rather than static receivers?

[grant]

This would greatly simplify a lof of the extra logic I see in the module.

We can always add in protocols later, but I suggest removing it for now.

[lance]

I actually have tentative requirements for MQTT, AMQP and/or Kafka and that's why Receiver optionally accepts a protocol. I can see an argument to be made for making accept() a static method on Request or even just a standalone function. This would mean that we would need to add a third, optional protocol parameter to accept().

[grant]

I'm fine having an optional parameter to accept() rather than 100 dangling CloudEvent acceptor objects in my code.

I know that is a stretch, but I'd really like it to be static, or at least have the option of being static.
With CloudEvents, things are fully-encapsulating and stateless, so the less state we can have, the better.

Happy to keep the protocol list and have TODOs for those other protocols, especially if you might have requirements for them.