(PR ready) Feature request: Cancellation token handling and Rust support

[Xerxes004]

Currently, C# cancellation tokens just directly call the tokio task abort function when cancelled. Using the tokio-util crate, this can be made more robust using Cancellation Tokens. These offer a nice way to recover gracefully on the Rust side of the FFI interface, rather than the task being dropped at the next await synchronization point.

I've created a pull request that does a few things:

1. Adds basic cancellation token support via tokio_util::sync::CancellationToken. This is guarded behind the tokio-ct feature flag.
2. Adds a basic asynchronous programming example to the production example project

(PR draft #281)

[ralfbiedert]

I'm generally open to something like that. This should be runtime agnostic somehow, i.e., if we support more than tokio, this has to work with other runtimes enabled, possibly at the same time. Also, the underlying code shouldn't get too gnarly.

[Xerxes004]

I like that idea and I think the current implementation already supports that with a little elbow grease. Maybe utilizing runtime_ as a prefix to detect another runtime available would make it more user-friendly?

#[ffi(service)]
#[derive(AsyncService)] //
pub struct MyService {
   runtime: Tokio, // default runtime
   runtime_smol: Smol // impl AsyncRuntime, exposes `.smol` field in Async<Self> via proc macro
}

#[ffi]
impl MyService {
    // ... snip ...
    pub async fn do_tokio_task(this: Async<Self>) {
       // etc etc
      this.spawn(...).await
    }

    pub async fn do_smol_task(this: Async<Self>) {
       this.smol.spawn(...).await
    }
}