[WIP] Prototype a Dispatch2 trait to dispatch delegate macros to oblivion

[ids1024]

I've though of some alternate ways to define Dispatch (as an alternative to the change in Smithay/smithay#1327). Today I had an idea for a way to prototype such a thing outside of wayland-rs. Due to the orphan rule, we can't create any blanket impls of Dispatch that are generic over the State the trait is implemented for (unless our crate is the one that defined the type I). But we can provide a delegate_dispatch2! macro that will add such a blanket impl for a particular concrete type.

Dispatch2 is similar to wayland_client::Dispatch, but it's now implemented for the object user data type instead of the state type, uses &self for the argument pointer to the user data, and removes the extra State = Self type bound.

Implementing this for the user data seems reasonable, since we already need to pass a user data when sending a request that creates an object. So the type passed there indicates what dispatch implementation to use. (It would also work to use State: Dispatch<UserData, I> instead of UserData: Dispatch<I, State>; but it would not work to use State: Dispatch<I, UserData> where I is a type from a different crate and State is generic. That isn't allowed under the orphan rule. So of the alternatives that work, this draft uses the one that seemed best to me.)

This draft uses Dispatch2 and eliminates the dispatch macros used in the simple_window example, except:

• We can't make this generic over KeyboardDataExt, PointerDataExt, SurfaceDataExt, RequestDataExt (at least if this trait were part of wayland-rs, and not the same crate)
  • We can change the API to instead wrap the user data in a type provided by sctk. This would actually be potentially simpler anyway, since a trait impl wouldn't be needed. That isn't done here.
• For registries, we likewise can't implement for the GlobalList type, since that is a wayland-client type, not an sctk one

event_created_child() is unchanged, but we should think of better ways to handle that too.

It is still necessary to have Dispatch bounds in methods of the *State types that create objects, but not in the implementations of Dispatch2. Though type bounds shouldn't be needed anymore if this were moved to wayland-rs and replaced Dispatch.

If an API change like this is good, it could be incorporated in the next breaking update to wayland-rs. Does anyone see non-obvious issues with this?