can't use tokio feature if a transient depends on accesskit with default-features

[lunixbochs]

8f937ba makes default-features incompatible with the tokio feature
Talon depends on zbus with the tokio feature, so it needs to depend on accesskit with the tokio feature
Talon depends on egui
egui depends on accesskit with default-features (egui shouldn't need to decide about accesskit_unix's executor anyway)

Talon -> egui -> accesskit (default-features=true) enables the async-io accesskit feature
Talon -> accesskit (features=[tokio]) enables the tokio feature

accesskit now denies this:

error: Both "async-io" (default) and "tokio" features cannot be enabled at the same time.

this kind of defeats the purpose of the tokio feature in accesskit imo, as I shouldn't be expected to patch egui for default-features = false to use it

---

anyway, at this point I think nobody should use the zbus/tokio feature in a library crate, and we should instead use this approach for tokio support when the tokio feature is enabled in accesskit_unix

here's the commit where I did it for ksni: talonvoice/ksni@15e31db

for now I'm turning off accesskit/tokio, and I wouldn't mind turning it back on with the zbus tokio feature removed like in the ksni change

[DataTriny]

This use of features is a hack, I know. I would have expected egui to also expose similar features to let users decide which async runtime accesskit_unix should use.

AccessKit has to choose a runtime. The default is async-io, and I already saw some tokio users complain about having some dependencies on async-std.

If it's the only way to not cause a panic in any case, then the right choice is obvious.