Transparent axis/button IDs

[Ralith]

Per IRC discussion, this replaces the AxisId/ButtonId newtypes with type aliases, and relocates them to the events module. This makes generic input events usable in practice, and is more consistent with the existing ScanCode type.

Replaces #172.

[tomaka]

I'm in favor of this, but let's leave it open for discussion.

My reasoning is that basically an axis ID or a button ID is always no more than some sort of index. You can't add or remove axes or buttons for example. Therefore there is no reason for these to be opaque, and using a dedicated type feels like too much typing.

[Ralith]

For posterity: the motivation behind newtypes was to provide strong typing to avoid confusion between unrelated ID spaces in comparisons and possible future APIs to query for details (such as name or axis resolution and range). I think these are reasonable goals, but it's not totally obvious that accomplishing them with newtypes is a net ergonomic win: simple uses will likely be limited to matching on hardcoded values (e.g. 0/1 usually being X/Y axes), making the newtypes nothing but extra verbosity. Combining that uncertainty with the convention established by ScanCode and the improved convenience of type aliases for the inevitable operations that wouldn't be forwarded by a newtype (such as (de)serialization) I'm satisfied with the type alias approach.