Should wasi-tls be imported in the wasi:cli world?

Today we do not import wasi:tls in the worlds that we encourage runtimes to support, e.g. wasi:cli/run and wasi:http/proxy.

Should wasi:cli/run remain strictly to features of POSIX or is the intention to provide features that most CLI programs need (including SSL/TLS)? Today sockets are supported but making requests for insecure sockets is (or at least should be) rare.

Some options:

• Add wasi:tls to imports and thus the run world behind a feature gate, e.g. cli-with-tls.
• Introduce another world in wasi:cli, e.g. run-with-tls or cli-secure
• Add a world to the wasi:tls proposal that is essentially the above, wasi:tls/run
• Introduce a different batteries included proposal. I often write programs that import both wasi:cli/imports + wasi:http/outgoing-handler and would depend on wasi:tls once it reaches phase 3 and is well supported by the ecosystem, .e.g cli-net-tls.

Start by comparing the wasi:cli/run and wasi:http/proxy worlds and how they currently relate to wasi:tls. Review the listed alternatives, including feature-gated imports and additional worlds, and determine which approach best defines TLS support for common CLI programs. Done means reaching a clear decision on the world and feature design.