wasi: clearly document sandboxing & file system security status

Currently we use the term "sandbox" in the node:wasi documentation, which can be misconstrued as forming a security model.

This PR firstly removes the usage of the term "sandbox" and then also updates the docs to include a warning that WASI in Node.js is not a secure capability system and that this is not part of the Node.js threat model. This is very similar to what we already do for the VM module in being clear it does not provide a comprehensive security model for running untrusted code.

Finally, this PR adds a new section on Security to the WASI docs. If we improve the security properties in future, this versioned security documentation can form part of the contract of the implementation so that we can treat the addition of any security guarantees in future as a feature. Perhaps we never get there but it at least leaves the door open to that.

In terms of what would be required to claim our implementation does in fact provide secure sandboxing - the main issue right now is that the filesystem sandboxing is escapable via timing approaches with symlinks. The way to solve this from a security perspective would be to expose the openat primitive in libuv and use that to build a secure model. I created a discussion issue for this in https://github.com/libuv/libuv/issues/4167. This would have a slight performance cost, but would form the correct primitive to provide a secure filesystem sandbox.