Improve diagnostics on forbidden file write

When a guest attempts to write to the file system, it gets a "permission denied" error. For developers not familiar with Spin's stateless model, the reason for this can be non-obvious - after all, Spin itself has permission to write to the mapped directory - and can send them on a wild goose chase.

The current error is certainly the right result to return to the guest, but it might be good if we can provide more information to the operator (developer), indicating to them that:

• Writes are intentionally forbidden by default, because in general Spin runtimes are stateless.
• Writes can be enabled in the CLI environment, although this will hamper portability.
• There is documentation to help you figure out how to achieve what you want to. (TODO: check that there is. Write it if there isn't)
  • You should also read the documentation for your target deployment environment because nobody likes surprises.

This is currently tricky because we defer all permissions stuff to Wasmtime - we just preopen the tempdir with read only permissions, so have no opportunity to intercept writes and do something more informative with them.

Start by tracing where Spin preopens the temp directory read-only and how Wasmtime reports forbidden writes. Then inspect the CLI environment options and the relevant documentation. Done means operators receive an explanation of stateless write restrictions and available configuration or deployment guidance, while the guest still receives permission denied.