Add HTTP endpoint as delivery option for QS Cloud webhook calls

[mountaindude]

Background

Current implementation uses a serverless function acting as a http-to-mqtt gateway, then a MQTT broker on public Internet as a way to de-couple Butler from QS Cloud.
While this works very well and solves the situation where Butler must not be exposed to Internet, it does add complexity to the setup process.

New feature suggestion

Would be good to have the option to point the outbound QS Cloud webhook (that fires when an app reload fails) directly to Butler.
This could be a good option when Butler is not running on-premise in a corporate network, but rather in an Azure/AWS/GCP/... container environment, or in a DMZ (into which calls from Internet are allowed) in the corporate network.

Requirements

• The new Butler endpoint should support https.
  A challenge there is the certificate. In many cases it would not be practical to have a full blow TLS certificate issued by a CA, but rather use self-signed certificates (that then need to be deployed to QS Cloud somehow...). Or not. Needs to be thought through.
• Butler should dissect the incoming call to determine what it is about.
• Use the webhook secret (defined in QS Cloud for the webhook) as a (crude) way of authenticating the incoming call. Given how QS Cloud currently works that is about the only auth mechanism possible.