On self-hosted installs, several of these apps are not (currently)
available, meaning that `get_app()` would fail and we would get null
values in the suggested_apps array. Since the `/open_file` API endpoint
selects the first result, it could therefore think that there were no
available apps, when actually there were.

For example, source code files can be opened either in `code` or
`editor`. `code` is not available on self-hosted, so the first entry
would be null. This change removes that, so `editor` is rightly
selected.

Also, we have this `file_extension` variable, so let's use it. :^)

`open FILE|URL` opens the given file in the user's preferred app.

On Node, we rely on the system's built-in utility rather than attempt to
write our own code for figuring out what the preferred application is.

On Puter, `puter.ui.launchApp()` can't yet grant access to files, so
using `open` on Puter launches the app without the file open.

The other issue is that we need to make the app-launching code from the
CommandProviders available to coreutils and elsewhere, so that they can
interact with stdio without duplicating all the logic.