Allow trait interfaces without a Send + Sync bound
We currently add this bound, but I don't think it's always necessary. For example, a sync function that inputs a callback interface and uses it while it's executing, but then discards it. The callback interface does not cross a thread boundary, so there's no reason to make have Send + Sync as supertraits.
The UniFFI-generated struct that implements the trait will still be Send + Sync, but this would allow a Rust struct that's not Send + Sync to be compatible with the function. Since the UniFFI-generated struct implements Send + Sync, I believe this means the Rust code can add those as supertraits if they want and everything will work fine.
I'm not sure what the syntax should be, maybe we add a [NoSendSync] attribute in UDL. Do we need anything for proc-macros or could they parse the supertraits in the trait definition?
If there's no bound, then I think we should prevent these from being passed from Rust to the foreign language, since we have no way from preventing the foreign code from moving the interfaces to a different thread. At some point maybe we could also have an option to opt in to this and let UniFFI consumers communicate the thread-safety guidelines to their users.