Fall back to on-caller-thread execution on failure to create threads

[jcaesar]

Playing around with exa on wasi, I ran into the following problem:

thread 'main' panicked at 'failed to spawn thread: Custom { kind: Other, error: "operation not supported on this platform" }', /rustc/1d0d76f8dd4f5f6ecbeab575b87edaf1c9f56bb8/library/std/src/thread/mod.rs:620:29
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
error: failed to run `wasm-target/wasm32-wasi/debug/exa.wasm`
│   1: WASI execution failed
│   2: failed to run WASI `_start` function
│   3: RuntimeError: unreachable
           at __rust_start_panic (exa.wasm[8755]:0x1d08f4)
           at rust_panic (exa.wasm[8738]:0x1cff91)
           at std::panicking::rust_panic_with_hook::h7412819944345424 (exa.wasm[8731]:0x1cfb69)
           at std::panicking::begin_panic_handler::{{closure}}::h4738c0049ce98322 (exa.wasm[8706]:0x1ce936)
           at std::sys_common::backtrace::__rust_end_short_backtrace::h8bb6e3f06234953f (exa.wasm[8705]:0x1ce877)
           at rust_begin_unwind (exa.wasm[8730]:0x1cfa0d)
           at core::panicking::panic_fmt::h904ce09f3cb14707 (exa.wasm[8849]:0x1d7c4c)
           at core::option::expect_none_failed::ha29c9c4296a18e58 (exa.wasm[8878]:0x1dc21f)
           at core::result::Result<T,E>::expect::h5f8eb30bfbdbaae3 (exa.wasm[6426]:0x16569e)
           at std::thread::spawn::h3cc89fd93996815a (exa.wasm[6861]:0x175df8)
           at scoped_threadpool::Pool::new::hdb73697c8b248dc9 (exa.wasm[6610]:0x16b029)
           at exa::output::details::Render::render::h91ebcc5bfc6ddf7b (exa.wasm[621]:0x3057f)
           at exa::Exa::print_files::had7faa7210e822d5 (exa.wasm[1520]:0x70fe2)
           at exa::Exa::print_dirs::h7ab0fb5f5fc3ee36 (exa.wasm[1521]:0x731ee)
           at exa::Exa::run::h51601c14538dd750 (exa.wasm[1518]:0x6ff1a)
           at exa::main::h9fdb24dc7ef4e0e6 (exa.wasm[1516]:0x6eea2)
           at core::ops::function::FnOnce::call_once::h3e0755e2e5267419 (exa.wasm[2893]:0xc797c)
           at std::sys_common::backtrace::__rust_begin_short_backtrace::h63420e9eb2b23429 (exa.wasm[2600]:0xba96e)
           at std::rt::lang_start::{{closure}}::h29d44bec1a55a1d5 (exa.wasm[844]:0x43118)
           at std::rt::lang_start_internal::h0e1571f3e9f07dad (exa.wasm[8739]:0x1d00a2)
           at std::rt::lang_start::h913e5a18abb8a76d (exa.wasm[843]:0x430ca)
           at __original_main (exa.wasm[1522]:0x73e7e)
           at _start (exa.wasm[19]:0x2b4f)
╰─> 4: unreachable

So I made some small changes to be able to use scoped_threadpool on platforms without threads.

That being said, I'm unsure whether doing this is a good idea. There doesn't seem to be a good way to know whether thread creation failed due to a platform limitation or other reasons (I refuse to parse error messsage strings), and this is semantically a breaking change, since the spawned tasks may wait for some action on the main thread inside the Scope, which may never occur if the no-thread fallback is activated.

If you have any opinions on this, I'd love to hear them. Accept? Hide behind a feature or target_os gate? Better ideas? Better not?