feat(plugins): session manager cwd and new filepicker

[imsnif]

This PR started out as being about making it possible to choose the working directory of a new session through the welcome screen, but ballooned a little into other areas and includes lots of additional improvements.

The basic user facing functionality that was added

1. The ability to specify a folder when starting a new session (either from the welcome screen or from the session-manager)

What we're seeing here is the welcome-screen (the session-manager plugin) calling the user's filepicker (by default the built-in Strider plugin is used). The user selects a folder with the filepicker, then the filepicker sends this folder back to the session-manager and closes itself. The session-manager knows to start the new session in this folder.

2. A new filepicker (Strider revamped), with fuzzy-finding and autocompletion - which can be used either stand-alone or as part of a CLI pipe:

What we're seeing here is the user invoking the filepicker plugin (by default the built-in Strider plugin is used, but any other plugin with the same interface can do this), choosing a file with its interface and then the file being sent to the STDOUT of the CLI command. We also see here a demonstration of how this can be used in a shell pipe to choose files for commands interactively rather than typing them out in the middle of the pipe itself.

Infrastructure changes

1. When a plugin alias specifies a cwd
   eg.

filepicker location="zellij:strider" {
    cwd "/"
}

This CWD will be used as the location of the plugin (and the plugin given access to this part of the filesystem). When the plugin is launched, the CWD of the current folder will be passed as a configuration to it called caller_cwd. This is so that the plugin can provide a good user experience (eg. start in the caller_cwd) while still having the filesystem access explicitly given to it by the user.

2. Zellij now no longer implicitly starts watching the filesystem if plugins subscribed to one of the filesystem update events (eg. FileSystemCreate, FileSystemUpdate, etc.). Instead, plugins now need to explicitly call the watch_filesystem API in order for this to happen (note that this API is not the most stable and should probably be avoided if possible - cross-platform filesystem watching is a non-trivial problem I look forward to spending more time on in the future).

3. The scan_host_folder API method was added to plugins, so that they can explicitly ask Zellij to scan a host folder and report the results asynchronously through the FileSystemUpdate event (which the plugin also needs to subscribe to as usual). This is significantly faster than doing so through the native WASI filesystem methods due to fs::readdir performance in wasi is not great wasmerio/wasmer#4475. This is a stopgap solution so that we can provide a performant way of doing this without switching out our whole runtime.

4. The get_plugin_ids method now also returns an initial_cwd which is the location of the /host folder on the user's machine. So this to facilitate plugins showing their location in the UI and "doing the right thing" with stringifying selected paths (eg. so that the user will select /home/aram/code/zellij rather than /host/zellij for example.

Infrastructure conventions

This PR introduces some conventions regarding inter-plugin communication through message pipes. The user facing parts of this PR include the session-manager plugin communicating with an arbitrary filepicker plugin (implementing internally using the built-in Strider file explorer). While the message-passing pipe interface is generic enough to plug in any other filepicker plugin and have it work in the same way from the perspective of the session-manager (or really - any other plugin that needs filepicking functionality), some conventions must be adhered to to make this possible:

1. To send a message to the user's "filepicker" plugin, the destination of the message should be the "filepicker" (with no file/http/zellij prefix) so that Zellij knows the target is the "filepicker" alias. This message should include the "filepicker" message-name so that the filepicker knows this is a "filepicker" message and should be treated accordingly (this is because the filepicker can also potentially handle other sorts of messages).
2. The response from the filepicker will be sent over a new pipe, directly to the calling plugin, with the "filepicker_result" message name. Any args passed to the "filepicker" should be returned in the filepicker_result as is so that the calling plugin could (for example) identify this message with a request_id and be able to track it.
3. The payload of the filepicker_result pipe message should be an absolute path of a folder on the host machine (presumably the one the user chose).
4. Plugins using the filepicker to let the user pick a path may decide to either open a new instance of a filepicker just for this purpose, or to use any existing instance the user has opened. To do the former, they should include a random string in the configuration sent through the pipe-message. Zellij sees the uniqueness of plugins by their target (the "filepicker" alias in this case) and their config. A random string in the config will ensure a new instance will be opened (the session-manager uses the same request-id it generates and places in the args for this purpose in the config). There is no right choise about opening a new instance or not, and it's mostly a question of desired user experience. Each approach has its own merits and is situation dependent.
5. Filepicker plugins may or may not close/hide themselves after the user picked a file - this is UX dependent and up to the filepicker plugins.

[chanson02]

#195 implemented?

[imsnif]

#195 implemented?

hah, nice one