Ensure HTTPReceiver is sniffing events according to the specification #136

Currently, in the 1.x specification it says that, when the Content-Type header is not prefixed with the Cloud

When the Content-Type header is not prefixed with the CloudEvents media type, being able to know when the message ought to be attempted to be parsed as a CloudEvent can be a challenge. While this specification can not mandate that senders do not include any of the CloudEvents HTTP headers when the message is not a CloudEvent, it would be reasonable for a receiver to assume that if the message has all of the mandatory CloudEvents attributes as HTTP headers then it's probably a CloudEvent. However, as with all CloudEvent messages, if it does not adhere to all of the normative language of this specification then it is not a valid CloudEvent.

That's close to what the implementation is doing, but not quite. At the moment, it's just assuming that an incoming request is a binary event if the content type is not a CloudEvent media type. Instead this should error.