Add assoc. type Widget::Data, Events::Data

[dhardy]

This is vaguely a partial re-implementation of #387. Nothing actually uses "input data" yet; it always has type () or W::Data where W: Widget is the principal child type. But it is passed everywhere, layout the ground for the next part.

Unlike #387, there is no ConfigCx / EventCx which combines a ConfigMgr / EventMgr with input data. This approach was neat, but ultimately I don't believe it worth the additional complexity. Passing data: &Self::Data everywhere is a little more verbose, but not too bad.

Just like #387, there is a Node type combining a widget reference with its expected data. There is also NodeMut, since, unlike #387, I have not removed non-mut wiget tree introspection.

Unlike #387, most event-handling methods have been moved to Events which is not a supertrait of Widget, hence both have associated type Data. We require that both match (#[widget] allows only one definition and injects the other). I had considered supporting at least Events::Data = () while Widgets::Data is something else (several widgets such as Button and Frame should pass data through to children but don't use it themselves), but that would be extra complexity we don't need hence is not supported.

Also unlike #387, user data may be added to the UI's root (the "shell") and shared between windows. Properly using this will require the ability to add a message handler to the root. This caused a complication since pop-ups are currently embedded anywhere in the widget tree, and accessed via the usual tree introspection methods (Widget::get_child/_mut), including from Layout::find_id and draw — but the latter do not have data while get_child now requires data. This could have been resolved with a non-data variant of get_child, but instead of adding that everywhere I added alternative Window::find_id, draw methods which require data input (hacky, but probably the best option). I briefly considered revising pop-up code, but if we ever want pop-ups to be able to use input data then we need to keep them in the widget tree. Arguably this could be an option in the future, since tooltips and menus probably don't need input data, though perhaps a ComboBox over a ListView of entries using input data would be useful.

[dhardy]

This also updates to syn v2 (was intending to leave until later, but that would have meant writing v1 specific code).