Implement API-driven UI For Improved Plug-able Providers

[mastercactapus]

What problem would you like to solve? Please describe: As part of the ongoing efforts noted in issue #2639 to implement plugins/plug-able providers for notifications, we aim to continue this overhaul by making the UI elements like contact methods, escalation policy step assignments, and schedule notifications API-driven rather than hardcoded.

This aims to ease maintenance on current providers, and more importantly, is the core requirement for allowing plugins, where the provider types/names/etc won't be known until runtime.

Describe the solution you'd like: We require the addition of new queries for the different types that will be used in form building (e.g., the contact method form, or the escalation policy step dialog), a generic query for searching (e.g., for things like Slack channels), and corresponding updates to the UI to make use of these API-driven elements.

This follows a similar approach we've successfully implemented by introducing an integrationKeyTypes query.

Describe alternatives you've considered: Currently, no other alternatives have been considered due to the necessity of API-driven UI for implementing plugins.

Additional context: This is continuation of previous efforts noted in issue #2639, aiming to implement plug-able providers.

[mastercactapus]

One proposal keeping notification channels and contact methods separate:

notificationChannelTypes: [NotificationChannelTypeInfo!]!
userContactMethodTypes: [UserContactMethodTypeInfo!]!

type NotificationChannelTypeInfo {
  id: ID!

  name: String!
  label: String!
  enabled: Boolean!

  supportsSearch: Boolean!
}

type UserContactMethodTypeInfo {
  id: ID!

  name: String!
  label: String!
  enabled: Boolean!
}

notificationChannelSearch(input: NotificationChannelSearchOptions!): [NotificationChannelInfo!]!

input NotificationChannelSearchOptions {
  type: ID!
  search: String
}

type NotificationChannelInfo {
  id: ID!
  type: ID!
  name: String!
}

[mastercactapus]

We will likely keep Slack user groups out-of-scope for this, as it's more of an automation with error reporting than a notification destination; that type of thing doesn't fit well with any of the other delivery methods and should have its own criteria.