Installation does not model situations where multiple Incoming Webhooks are created in a single workspace/organization

Description

Currently the Installation object contains a single incomingWebhook property, as an object with several properties. That works when an OAuth flow completes and the installation needs to be stored since a single installation can generate at most one Incoming Webhook. However, when another installation in the same workspace or organization occurs, it will create a new Incoming Webhook. This might also be fine if you're happy with the InstallationStore storing a new record for this installation, even though most of the data in it is duplicative. However when fetching that installation, the InstallationStore returns a single Installation object, which can only contain one Incoming Webhook. That means one of the two Incoming Webhooks is not reachable.

One possible solution is to update the interface for Installation so that the incomingWebhook property becomes incomingWebhooks, which contains an array of the created webhooks instead of just one. However we'd have to figure out how InstallationStores are meant to merge the individual installations into one. This might require a redesign of that interface, and updated implementations.

Another solution is to update the return value of fetchInstallation() to be an array of Installation objects. This would be simpler to implement, but would encourage storing duplicative data .

There may be other good solutions available. Let's brainstorm and discuss.

Requirements (place an x in each of the [ ])

• I've read and understood the Contributing guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.
• I've searched for any related issues and avoided creating a duplicate issue.

Start by tracing the Installation object, InstallationStore, and fetchInstallation() entry point through their implementations. Compare how multiple installations in one workspace are stored and retrieved, then determine a consistent interface that preserves every Incoming Webhook; done means the chosen design is specified and its affected implementations are updated without losing webhook data.