[RFC] Add a FileSystemProvider to allow editing objects remotely

VS Code provides an API for extensions to register new filesystem schemes: https://code.visualstudio.com/api/references/vscode-api#FileSystemProvider.

It could be very cool to be able to map openHAB objects as reported by the REST API (therefore allowing to edit managed objects the JSON DB remotely) to virtual files in a openhab:// scheme, maybe like this:

openhab://{host}[:{port}]/
  +-- items
   |- gKitchen.yaml
   |- HueKitchen.yaml
   |- HueKitchen_Brightness.yaml
   \ ...
  +-- pages
   |- floorplan_groundfloor.yaml
   |- home.yaml
   |- layout1.yaml
   |- overview.yaml
   \ ...
  +-- rules
   |- back_home.yaml
   |- leaving.yaml
   |- scene_bedtime.yaml
   |- python_test.yaml
   \ ...
  +-- sitemaps
   |- default.yaml
   |- example.yaml
   \ ...
  +-- things
   |- hue_bridge1_23.yaml
   |- mqtt_broker_broker1.yaml
   |- mqtt_topic_broker1_sensor1.yaml
   |- network_bridge1_23.yaml
   \ ...
  +-- widgets
   |- heating_thermostat.yaml
   |- multimedia_player.yaml
   |- widget123.yaml
   \ ...

That way it would become possible to open a "file" like openhab://openhabianpi:8080/things/mqtt_topic_broker1_sensor1.yaml. Other UI elements in the extension could take advantage of that, for example a "Open" menu entry in the Things/Item editor. Maybe even add the entire openhab://host:port root directory to a workspace and see the contents in the file explorer, like the MemFS sample here: https://github.com/microsoft/vscode-extension-samples/tree/main/fsprovider-sample

memfs sample

The host:port part could be optional since the extension supports a single server in settings.

Some initial considerations:

It wouldn't be possible to 1) create additional folders, 2) copy/move a file to another folder, 3) create a file without the proper extension/file name format
Depending on the file's folder, different endpoints in the REST API would be called for readFile/writeFile/readDirectory/stat/delete; the files contents would be a general rule the YAML serializations of the objects as returned by the API, not JSON, in a manner consistent to what the UI does in its Code tabs (some light processing could be done to strip the output of unnecessary runtime information);
Renaming files (rename) could be possible (within the same directory) which would involve deleting the current one, and creating a new one with the UID (depends on the file type) set to the filename part without the extension
Dynamic JSON Schemas could also be provided by adding inline comments in the YAML files (https://github.com/redhat-developer/yaml-language-server#using-inlined-schema); these JSON schemas could also be provided in the openhab scheme, for example, openhab://host:port/schemas/thing-types/hue_bridge.json, which would in particular translate the config parameter descriptions to the proper JSON Schema format so we could in theory have YAML intellisense for these when editing the YAML. Similarly, item contexts could offer a list of item names to complete.
For sitemaps, not sure if YAML or the sitemap definition grammar should be used (the UI can work with the latter so it could in theory be ported)

openhab / openhab-vscode

[RFC] Add a FileSystemProvider to allow editing objects remotely #248