Add Import Files... command that supports many file types

[isc-bsaviano]

This PR fixes #1763 by removing restrictions on the existing Import XML Files... command. The underlying server APIs support many file types, so it's easy for VS Code to do so as well. This also make the Import Local Files... command redundant, so I removed it. I kept the vscode-objectscript.importXMLFiles command ID in case anyone made a keybinding for it, but I am also open to changing it to something like vscode-objectscript.importFiles.

[isc-klu]

Why aren’t we concerned about key bindings for other command IDs? Do they simply not appear in the telemetry data?

[isc-bsaviano]

We capture no telemetry data on user keybindings. It should be possible to add.

[isc-klu]

That helps, thanks. I’m curious why we were comfortable deleting importLocalFilesServerSide, but chose to preserve importXMLFiles. Is there a reason to believe the latter is more heavily used or more likely to be bound by users?

[isc-bsaviano]

@isc-klu We have telemetry on command execution. Over the past 90 days, importLocalFilesServerSide has been run 453 times, while importXMLFiles has been run 1033. XML also has it's own documentation page, which the other has a small reference. I am fine with changing the command ID. We do not have any good reason to believe that someone has assigned either command to a keybinding. The docs will need to be updated regardless.

[isc-bsaviano]

I updated the command ID

[isc-klu]

I see — that makes sense. Updating importXMLFiles clearly incurs a higher documentation burden, given the dedicated docs page it already has.

If backward compatibility is a strong requirement here, I think the right approach would be to introduce the new command (importFiles) and make all existing commands aliases of it.

If we’re comfortable with a breaking change, then the current approach—removing the old commands outright—is reasonable and probably the simplest path.

[isc-bsaviano]

This is going to be a nontrivial documentation effort no matter what the command ID is. The only question is if we should keep the same command name to preserve any custom keybindings. Since the command's functionality changed meaningfully, I think a new ID is warranted.