Expose generic document provider API

[davidbrochart]

Problem

Currently the document providers are kept private inside the drive. But there can be a need to programmatically create providers and have access to them from outside the drive, like in JupyterCAD where the kernel wants to connect to a shared model that is synchronized with a file.
Also, it would be nice to have a transport-agnostic provider interface, so that a client can "connect to a file" without knowing if it's using e.g. jupyter-collaboration or jupyter-shared-drive (which use WebSockets and WebRTC, respectivelly).

Proposed Solution

Extract out a document provider API and have it use a transport-agnostic interface.

[davidbrochart]

Actually, the drive has a sharedModelFactory that can be used to create a shared model through its createNew() method, passing it the file name.
A first PR in JupyterCAD is using that, rather than dealing with the internals of the drive (WebSocket provider, etc.). Now I think that the ICollaborativeDrive should not belong to jupyter-collaboration, but should instead be extracted out to an independent package, say jupyter-collaborative-drive, that jupyter-collaboration would depend on. Other implementations of collaborative drives, like jupyter-shared-drive, could provide an ICollaborativeDrive, which JupyterCAD could use instead of jupyter-collaboration. Because jupyter-share-drive doesn't need a backend, this would allow JupyterCAD to work in JupyterLite.