See #123160

After some discussion: this is where we landed:

• Have a requiresMessaging: boolean | 'optional' option on the notebookOutputRenderers contribution. Defaults to false, but if true then the context provided to the notebook renderer's activate will have a postMessage and onDidReceiveMessage event. If optional, it may have these properties.
• In the extension host, there is a new API:

   export interface NotebookRendererMessaging<T> { // mirror of the renderer API interface
   	readonly onDidReceiveMessage: Event<T>;
   	postMessage(message: T): void;
   }
  
   export namespace notebook {
   	export function createRendererMessaging<T = any>(rendererId: string): NotebookRendererMessaging <T>;
   }

• VS Code will only load renderers with requiresMessaging: true in scenarios where they have a loadable extension entrypoint. For example, renderer extensions without a browser entrypoint will not be usable in serverless. aznb should not load renderers with side-effects.
• We should add methods for common cross-compatible operations, like file opening/reveals, to the renderer API itself.
• There will be a new onRenderer:<renderer id> activation event that extensions can use to activate when a renderer becomes active. This activation happens asynchronously, and events the renderer sends before activation completes will be buffered.
• We should remove command links (after a migration period) and recommend renderers use this instead

Q: Does this duplicate/make redundant kernel preloads?
A: The kernel preloads are an extensibility mechanism that multiple renderers can use and share. They are guaranteed to be loaded and available before any renderer is loaded. Additionally, they provide declarative constraints in renderer compatibility that can be reused across productions, where simply saying a renderer has sideEffects does not provide this.

cc @vijayupadya

Update: in VS Code, we don't support partial activation. After talking to Alex, doing this is hard, complex, and has wide-reaching implications. So, extensions that have a renderer with optional messaging and an entrypoint, but are running in an environment outside of their supported extensionKind, will be disabled as usual. (However this does not diminish its usefulness as a flag for use in other environments)