Handle Thread-Local Storage Properly for Async Tasks

It looks like there is a bug in Shuttle's implementation of Thread-Local Storage (TLS). Every task, whether it represents an OS thread or a future, currently gets its own TLS:

https://github.com/awslabs/shuttle/blob/89d938415f7aa7813673cd7668390b6cfb23cf3c/shuttle/src/runtime/task/mod.rs#L170

However, in real executions, only true OS threads get their own TLS. Async tasks inherit the TLS of the thread they are running on.

Reproducer:
https://github.com/awslabs/shuttle/compare/main...dylanjwolff:shuttle:tls-bug

I think modeling TLS properly requires some thought since the correct behavior actually depends how the (non-shuttle) async runtime delegates async tasks to different OS threads. Tokio [may move tasks across threads](https://docs.rs/tokio/latest/tokio/runtime/index.html#multi-threaded-runtime-behavior-at-the-time-of-writing), for example, but other async runtimes like [monoio](https://github.com/bytedance/monoio) do not.

Start with shuttle/src/runtime/task/mod.rs at the linked line and run the linked TLS reproducer. Compare the current per-task behavior with TLS inheritance across true OS threads, considering that Tokio may move tasks while monoio may not. Done means the model reflects the selected async runtime's thread behavior and the reproducer passes.

Written by the indexing model from the issue text.