Should we retire the `NotebookLite` directive altogether?

[agriyakhetarpal]

At the moment, we provide two directives: the JupyterLite directive and the NotebookLite directive, which link to the Lab and Notebook interfaces/apps, respectively. I'd like to ask if we can reduce this footprint and provide just one directive instead that combines both of them. Here is my rationale for this proposal:

• There is a bunch of shared code between both directives, for no good reason – all there is to the difference between their behaviours (i.e., the interfaces whose access they provide) is that the URL they open has /lab/ and /notebook/ respectively.
• This redundancy is also noticed across other features such as the REPL/Replite and the Voici directives, but we can argue that the REPL and Voici apps have a reasonably different use case – in comparison, the Lab and Notebook interfaces are very much alike, with the only difference being the extra features from the Lab interface and its novelty, and the sidebar that includes the file explorer.
• Sphinx-Gallery, which depends on jupyterlite-sphinx, also supports JupyterLite notebooks through its jupyterlite dictionary option, and it, too, makes no distinction using separate options or directives: it provides use_jupyter_lab which uses the Lab interface if set to True, otherwise it uses the Notebook interface.

The newer implementation could look simply like this:

.. jupyterlite:: notebook.ipynb
   :app: lab
   :height: 600px
   :width: 100%

.. app above can be either "lab" or "notebook"

This is the same solution that has been suggested in #114, however, what I suggest here is much more limited because I'm only concerned about these two directives, with a decision on the Replite and the Voici directives left for a different/later issue.

If we agree, some troubles with the implementation that can arise are:

• #114 was opened at a time when we were still very early into the development of the extension, and we have a bigger user base by now.
• Backwards compatibility: thus, while we have never had any (especially because we're still in our 0.x.y stage), there are downstream users who would still like some level of stability with what directives are available
• How do we plan for the migration of the rest of the directives at a later time – i.e., will this plan work well?

There are indeed steps to resolve the backwards compatibility issue:

• if/when the new directive options are implemented, assume that the default is "lab" if not provided
• issue a FutureWarning on the use of the NotebookLite directive
• mention it very clearly in the warning message on how to migrate
• wait for three releases for everyone so that adapt, i.e., gradual deprecation
• make the NotebookLite directive a no-op and a stub for those who don't use warnings-as-errors when building the docs
• drop it from the source code altogether