[gamepad] Reasoning behind GamepadButton struct

I've been working with the Gamepad API implementation in Chrome recently,
trying to bring it up-to-date with the latest editors draft of the spec (
https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html). While
generally I feel like it's a good update to the working draft I'm puzzled
by the decision to change the gamepad buttons from an array of floats to an
array of GamepadButton structures.

Specifically, it appears to add complexity to the interface and
implementation without providing new information to developers. I can see
that if a piece of hardware provided custom deadzones on axes which would
eventually be interpreted as buttons that it may be convenient to use that
to determine the "pressed" state, but no hardware I know of actually does
so. (XInput suggests a trigger deadzone of 30/255, but that's an arbitrary
guideline and probably works well for most similar hardware.) If there is
concern about input noise providing false positives "presses" for these
types of buttons it would seem pretty trivial for the browser
implementation to apply the deadzone internally, and only provide non-zero
values above the desired threshold.

I recognize that Mozilla has already implemented the API as described in
the editors draft, and I don't want to place additional burden on them to
change it unnecessarily. I'm happy to update Chrome's implementation to
match, but I want to ensure this is the right direction before I do. It's
also worth noting that many of the existing web apps that use the API
(though they are admittedly few) expect the buttons to be exposed as
floats, and as such updating Chrome's implementation will break these use
cases. (New fields like "mapping" and "connected", on the other hand, can
be exposed without requiring changes from the app).

I apologize if this has been addressed before, as I've only recently
started working on the implementation and am not familiar with the full
spec history. I haven't seen this particular point discussed in the
archives, however, so I figured it was worth bringing up.

--Brandon Jones