feat: adding webhooks as a notification channel type

[nataliekorzh]

• Identified the issue which this PR solves.
• Read the CONTRIBUTING document.
• Code builds clean without any errors or warnings.
• Added appropriate tests for any new functionality.
• All new and existing tests passed.
• Added comments in the code, where necessary.
• Ran make check to catch common errors. Fixed any that came up.

Description:
Adds support for webhooks as a notification channel.

Which issue(s) this PR fixes:
Part of #2691
Splitting up #2774

[mastercactapus]

As I'm going through this, I wonder if we should qualify Webhook everywhere to reduce ambiguity; nc-webhook and user-webhook vs. webhook on its own for either one.

Thoughts?

[AlaricWhitney]

Since there will be more than one type of Webhook, we should ensure that there's a prefix to help everyone know what kind of webhook it is.

[nataliekorzh]

As I'm going through this, I wonder if we should qualify Webhook everywhere to reduce ambiguity; nc-webhook and user-webhook vs. webhook on its own for either one.

Thoughts?

Just added the new chanWebhook type

[mastercactapus]

Trying to validate this functionally, I'm not able to create a webhook channel via the API -- I'm attempting to do so via creating an EP target:

[nataliekorzh]

If I add the new escalation/store.go file included in the original PR (#2774), webhooks can be created successfully via the API. I was planning to include that file in a future PR where I set up the backend for adding a webhook to an escalation policy step. This PR was just for setting webhooks up as a new notification channel type. Do you think it would be better to include that file in this PR and allow for the functionality now?

[mastercactapus]

I see; having it here would certainly help validate the API and DB changes -- is it possible to include just the minimal API <-> DB bits? If not, we can leave it out of scope.

[nataliekorzh]

Sure, just added it.