This issue covers the architecture review and polish @DonJayamanne and I are working on. The main goals of this task are

• Finalize how the APIs from src/kernels are being used by the core system (notebooks, interactive-window etc) and 3rd party extensions. There will be restriction and clear separation between internal and external use of the kernel interfaces.
• Internal architecture review and polish of src/kernels component. The kernel component will stay minimal and limited responsibilities without worrying about business logics of how kernels are being used (i.e., how to read variables, how to install dependencies into the kernels, etc)

Here is a list of tasks we will tackle:

• Strict IKernel with notebook document linked in core
  • Strict IKernel with notebook document linked in core. #10817
  • Internal system always create IKernel with NotebookDocument, it's 1-to-1 mapping.
  • 3rd party can create kernels from Uri instead of NotebookDocument
• Conditional notebook controller for cell execution Remove controllers from ThirdParty Kernels #10884
  • 3rd party can create kernels, which don't require a VS Code NotebookController to be created
• Remove explicit knowledge of interactive window from IKernel
  • Unify node/web kernel and remove iw reference in kernel component #10853
  • Both Interactive Window and Debugging feature require special initialization after jupyter session is started. StartupCode can be registered from IW and Debugging other than embedding the logic into IKernel
  • The fix would be similar to how we add @multiInject(ITracebackFormatter)
• Debugging and Debug Variable can probably be moved out Rebornix/move debugger out of kernels #10870
  • Debugging and debug variable provider are used by notebook and interactive window so they probably don't need to live in kernels at all.
• 🏃 KernelFinder and KernelProvider Kernel Finder workflow #11153
• Review misplaced internal components
  • ipywidgets Experiment: move ipywidgets into notebooks #10903
  • port