This PR introduces the concept of SeerOperator and SeerEntrypoints. The Operator and Entrypoint will work in tandem to allow triggering and issuing updates to external services during a seer workflow (in this case, an autofix run).

• The SeerOperator handles all of the interfacing with seer and does not care or know about what service the entrypoint is talking to.
  • It connects to a registry of entrypoints, and when autofix updates come through, will signal to those registrants if they've previously interacted with a run.
  • It also determines what is needed from a third party signal (i.e. Slack Webhook) to trigger a seer workflow (for example, an organization, user, and group for autofix).
  • This will ensure any more entrypoints that get added later on (for example, Discord, MS Teams, or even non-chat integrations like GitHub comments) will also trigger the same workflows with the same signatures/contract
• The SeerEntrypoint is a protocol for that handles all of the interfacing with a specific provider, for example Slack.
  • In practice, specifying callbacks like on_trigger_autofix_error and on_trigger_autofix_success, the dev can create provider-specific workflows depending on what capabilities the platform actually has. For example, if in slack, maybe we send an ephemeral message to indicate we started a run, for github comments, maybe we just react.
  • You then implement create_autofix_cache_payload, which will be passed back to your on_autofix_update method when Seer issues a webhook. This is critical to back and forth interactions since we cannot do polling in Slack (for example).

In this PR, I've only implemented the entrypoint protocol, the actual slack entrypoint will come in a follow up. The operator is all there though, tests and all 👍