Allow wcmSoftOutEvent to cancel in-progress gestures

It is expected that when wcmSoftOutEvent is called, the driver will act
as though the pInfo device has gone out of prox. This works well for EMR
but does nothing about the gestures that our driver performs for touch.

To work around this, we rename wcmSendButtonClick to wcmSendTouchClick
and mark it extern. We then call it to ensure any held buttons are
released and force the wcmGestureMode to 0 (the GESTURE_NONE_MODE).
Remove unused function parameter
Change function signature of commonDispatchDevice

Changes commonDispatchDevice to take an InputInfoPtr rather than a
WacomCommonPtr. This is in prepraration for the next patch where
an InputInfoPtr will be required in wcmEvent. To make this happen,
the call to 'findTool' is moved to wcmEvent. This also allows us
to remove the one-off setting of 'priv' only for touch devices.

QUESTION: Is it safe to move findTool to this new location? Is
there any reason the tool would not be found here? Is it safe to
exit the function before the device state is saved with the
memmove below?
Support cross-device pointer arbitration

Currently pointer arbitration is taken care of through the use of
a 'wcomPenInProx' variable in the WacomCommonRec. If two devices
share a 'common' variable, the commonDispatchDevice function will
ensure that touches do not move the pointer while the pen is in
proximity.

This patch adds support for cross-device pointer arbitration to
prevent other touches known to the driver from moving the pointer.
This is achieved with the introduction of a 'WACOM_DRIVER' structure
that is shared by all tools. Inside this structure is an 'active'
variable that keeps track of the last tool which was actively
controlling the pointer. When an event from any tool comes in, the
driver will attempt to determine if it should be filtered or not.
In some cases, the new device will be allowed to take control of
the pointer, and become the new active device.

QUESTION: Is it correct to do aribration prior to saving the
device state with the memmove below? Is there any reason we
would want to keep around the "last" state from a tool that
was ignored?
conf: Match Hanwang tablets in their own section

Signed-off-by: Jason Gerecke <killertofu@gmail.com>
conf: Add new InputDevice matches based on USB and PnP ID

If the kernel's HID driver is used rather than wacom.ko, its very
possible that the device will not have "Wacom" anywhere in its
device name. To ensure we are able to match Wacom tablets in this
situation, we add matches based on the known USB and PnP IDs.

Signed-off-by: Jason Gerecke <killertofu@gmail.com>
WIP: Allow EMR to grab pointer control only when pointer is idle

This patch changes the how pointer access is arbitrated. Before,
any EMR tool would be immediatley granted control over the
pointer, preempting any tool that may have had it beforehand.
This could lead to "fighting" if two EMR tools were used
simultaneously.

Now, the driver allows a tool to maintain control of the pointer
so long as it is actively generating events. If, for instance,
a pen is brought in proximity of one tablet, a second pen
brought into prox of a second tablet will no longer cause
fighting over the pointer. Deciding if a tool is active based on
its last event timestamp rather than proximity allows a pen
to be used even if a puck has been left on another tablet.

*** NOTE ***

There's been back-and-forth on the issue of this kind of cross-
device EMR arbitration on Windows and Mac. For now, we're going
to continue to use existing behavior since nobody has complained.
IDEA: Don't touch device immediately enter in when the pen goes out

When using a touch-enabled tablet, if the pen goes out of prox any
touches will immediately be sent. We should consider ignoring them
as long as the touch is present (reset and allow after all touches
to up). The thought is that for things like the Bamboo or ISDv4 which
don't have a particularly large prox height, inadvertant touches will
be generated more often than desired.