[gamepad] New feature proposals: pose, touchpad, vibration

I'd like to propose the addition of several new features to the Gamepad
API, primarily born from needs that have been identified while developing
the WebVR spec <http://mozvr.github.io/webvr-spec/>, but which also cover
topics that have been under discussion in the past but deemed lower
priority for one reason or another.

First, I'm proposing that we add an optional "pose" object to the the
Gamepad interface that would expose all the information necessary to track
a controller with 3 Degree of Freedom or 6 Degree of Freedom tracking
capabilities. The primary motivator for supporting this information is to
allow devices like HTC Vive controllers or Oculus Touch to be exposed, but
the same structure could also expose motion and orientation data for
devices such as Wii, PS3, and PS4 controllers, as well as anything else
that had a gyroscope and/or accelerometer.

interface *GampadPose* {
  readonly attribute Float32Array? position;
  readonly attribute Float32Array? linearVelocity;
  readonly attribute Float32Array? linearAcceleration;

  readonly attribute Float32Array? orientation;
  readonly attribute Float32Array? angularVelocity;
  readonly attribute Float32Array? angularAcceleration;
};

partial interface *GampadPose* {
  readonly attribute GamepadPose? pose;
};

Position is given in meters from a device-specific origin. Velocity and
acceleration are given it meters per second, and orientation is a
quaternion. If provided all arrays should have 3 elements to except the
orientation, which has 4.

The proposed pose interface largely mirrors the VRPose
<http://mozvr.github.io/webvr-spec/#interface-vrpose> interface from the
WebVR spec, but drops the timestamp since that's already provided on the
Gamepad interface itself. The VRPose interface could conceivably be used
directly, but I'm assuming that we'd rather not have a dependency on a
separate work-in-progress spec.

Second, I'd like to see the API more explicitly support devices that have
touchpads. It's my feeling that the existing axis array is sufficient for
exposing the touch position, but we need a way to indicate if the touchpad
is currently being touched to disambiguate a value of zero from no input.
This can be handled currently by assigning a button to report pressed =
true when the touchpad is touched, but since many touchpads also can be
clicked as a button you end up with two buttons associated with a single
input. I'd like to proposed that we extend GamepadButton with a "touched"
boolean to make this case explicit.

interface *GampadButton* {
  readonly attribute boolean pressed;
  readonly attribute double value;
  readonly attribute boolean touched;
};

For non-touch controls it seems sensible that this would always report
false.

Finally, I'd like to propose that we add gamepad vibration controls. This
has been talked about in the past as well, and the thinking has typically
been that the Gamepad API may want to try and use the Vibration API
<https://w3c.github.io/vibration/> somehow instead of exposing a new
interface. However that API doesn't currently have a way to target anything
other than the device's default motor (usually for a phone), and I don't
see there being much interest in extending it to do so. Still, I don't see
much sense in re-inventing this wheel so I suggest exposing the same
interface on the Gamepad object.

partial interface *Gampad* {
    boolean vibrate (VibratePattern
<https://w3c.github.io/vibration/#idl-def-VibratePattern> pattern);
};

This is pretty basic as far as gamepad haptics go, but it's also provides a
lowest common denominator interface that should be supportable by anything
with a motor in it. It gives up some granularity (For example, it doesn't
allow developers to trigger the two motors in an Xbox controller
individually), but it provides a clean, universal interface that's easy to
use and mimics existing features on the web platform.

I've included several developers that have been participating in WebVR's
development to provide some feedback from that end of things. These are
some reasonably large additions, but they can be layered on to the API as
it stands today without breaking backwards compatibility and cover features
that have been discussed as possible additions previously. Hopefully we can
figure out a way to incorporate them that works for everyone.

--Brandon