Javascript plugin stdlib

Nobody has claimed this yet.

First of all, great work on tiled. I love it, and have used it for years. It pretty much works great for anything that uses tiles I have ever tried it with. Excellent software.

Recently, I was using [tiled-to-godot-export](https://github.com/MikeMnD/tiled-to-godot-export), which uses the javascript plugin API to generate godot map & tile definitions. It works pretty well, but in order to support relative paths, I had to roll my own path function (that is not nearly as good as node's `path.resolve`.)

It'd be really useful for plugin API to have some basic js stdlib type stuff like node's exec/os/path/fs for manipulating paths, spawning processes, introspecting the environment, and manipulating files, directly. In my opinion, keeping it as close as possible to the node API would be really great, since we can go light on documentation, and just point people there, and it will be familiar to experienced javascript devs. "It works like `path.resolve`" would be super-helpful to people like me.

I briefly explored the exposed `Qt` object, hoping it would have something in it, but I couldn't find anything related.

I am making this issue to start a discussion about it, and I am happy to help with anything I can, even though I don't do too much C++/Qt dev, I can get around ok, have a lot of experience with node, and could probly work out how to add support.

How should this look? Maybe a first step would be to make `path` bindings? If the `posix` and `win32` specific sets are stripped out, you get a pretty small surface, so it might be a useful & relatively easy starting point to expose:

```
path.basename(path[, ext])
path.delimiter
path.dirname(path)
path.extname(path)
path.format(pathObject)
path.isAbsolute(path)
path.join([...paths])
path.normalize(path)
path.parse(path)
path.relative(from, to)
path.resolve([...paths])
path.sep
path.toNamespacedPath(path)
```

The issue names no files or tests. Start by reviewing the exposed Qt object and the existing JavaScript plugin API, then compare the proposed path surface with Node's path API. Done would mean agreeing on the supported standard-library scope and exposing the selected path bindings with behavior matching the stated Node references.

Written by the indexing model from the issue text.