[PM-9598] Introduce integrations (#10019)

Factor general integration logic out of the forwarder code.

- Integration metadata - information generalized across any integration
- Rpc mechanism - first step towards applying policy to integrations is abstracting their service calls (e.g. static baseUrl)

Email forwarder integrations embedded this metadata. It was extracted to begin the process of making integrations compatible with meta-systems like policy.

This PR consists mostly of interfaces, which are not particularly useful on their own. Examples on how they're used can be found in the readme.

libs/common/src/tools/integration/integration-metadata.ts

@@ -0,0 +1,23 @@
+import { ExtensionPointId } from "./extension-point-id";
+import { IntegrationId } from "./integration-id";
+
+/** The capabilities and descriptive content for an integration */
+export type IntegrationMetadata = {
+  /** Uniquely identifies the integrator. */
+  id: IntegrationId;
+
+  /** Brand name of the integrator. */
+  name: string;
+
+  /** Features extended by the integration. */
+  extends: Array<ExtensionPointId>;
+
+  /** Common URL for the service; this should only be undefined when selfHost is "always" */
+  baseUrl?: string;
+
+  /** Determines whether the integration supports self-hosting;
+   *  "maybe" allows a service's base URLs to vary from the metadata URL
+   *  "never" always sets a service's baseURL from the metadata URL
+   */
+  selfHost: "always" | "maybe" | "never";
+};