3D proxy window design does not need an external-traces override for CheckDeviceGrabs after all

[Deron Johnson]

Earlier when Keith and I were talking about using proxy windows for 3D
objects in order to facilitate grabs for 3D objects, I indicated that I
thought we would need some way for the input redirector to impose its
own focus and sprite traces on the CheckDeviceGrab routine. I no longer
believe this is the case. All the input redirector client (i.e. the
picker) needs to do is to make sure that the parent/child nesting
relationships of the 3D proxy window hierarchy properly reflect the
parent/child relationships of the grabbable nodes in the scene graph
prior to sending down any picked events or before sending down a
SetInputFocus request.

The only other thing that needs to happen is for CheckMotion to
calculate the sprite trace for 3D events. Right now, in my prototype, I
only calculate the sprite trace for 2D events; the sprite trace for
3D events is left empty. This is something which will need to change.

Basically, what we in the CoreProcessXXXEvent routines is two types
of events: SubwindowResolved (aka 3D) events and SubwindowUnresolved
(aka 2D) events. The picker should mark each event as being Resolved
or Unresolved (we can use a bit in the child field for this).

Then, in CheckMotion, the subwindow will be determined for Unresolved
events and the sprite trace will be calculated. Only the sprite trace
will be calculated for Resolved events. Likewise, FixupEventFromWindow
will have different behavior depending on whether the event is Resolved
or Unresolved, and whether the destination window matches the current
event window field.