Platform support tracking issue

[NthTensor]

Add proper support for all major platforms:

• Standard std targets, as we already do.
• Embedded no_std targets.
• The web, ideally via web workers.

To support these platforms, we've got to figure out what we are going to do with these fundamental threading types:

• The Mutex used for the ThreadPool state.
• The Arc<AtomicBool> and Weak<AtomicBool> used for heartbeats.
• The Signal and Blocker primitives, both of which are build directly on Mara's amazing futex crate atomic_wait.

On std, these are all fine. For web, the web assembly atomics proposal supports exactly the futex wait and notify calls we need, with the caveat that creating web workers is not as simple as std::thread::spawn and we can never block the main js thread. We'll have to leave spawning and managing workers to users, and the build-system will suck, but that's acceptable.

For embedded, things are more complicated. None of these primitives will work, so we will either have to fall back to synchronous execution or add an async executor and go concurrent. Many no_std targets now have an async executor (like embassy for example), and it would be good if we could run on-top of them. On these platforms, users will need to set up a worker task, we won't use heartbeats, and block_on, join and scope will all have to be synchronous.

This boils down to the following features:

• the default: A core-only no_std fallback with only sequential operation, with no parallelism or concurrency.
• extern: Still no_std, but supports concurrency with externally added async workers.
• web-futures: A concurrent fallback based on wasm_bindgen_futures::spawn_local.
• web-worker: A full parallel thread-pool backed by web workers and wasm atomics.
• std: A full parallel thread-pool backed by the std operating system primitives.

[NthTensor]

After talking with @bushrat011899 I've come up with the following feature design:

• "none": Is no_std (core only), is entirely synchronous, eagerly evaluates everything.
• concurrent: Is no_std (core and alloc), lets you run forte on-top of any other async executor, join is synchronous but everything else works as expected.
• parallel: Uses std, this is the full hosted parallel thread pool (the current crate).

Both "none" and concurrent should both work on targets like wasm32-none-none. To make things simpler and avoid incompatibilities, parallel will extend/enable concurrent.

Additionally, the web feature will let us take advantage of browser apis:

• concurrent+web: Uses the portions of std compatible with wasm32-unknown-unknown, runs jobs using wasm-bindgen-futures, mocks async_task.
• parallel+web: Uses the portions of std compatible with wasm32-unknown-unknown, runs the full thread pool on web workers.

This should make it possible to run forte on basically any platform, taking advantage of parallelism and concurrency where it is available without significant effort to the end user.