Wiimote event parsing bug corrections.
Grrlblbrbrl
Remapped Wiimote NES mappings for no good reason
Improves the visual style for renaming games in library list view mode. Fixes #261.
Chooses the largest possible integer scale when setting the size of a pop out window (issue #391).
Set aspect ratio for GB
Ignores keyboard events in Preferences > Controls if the user hasn’t explicitly chosen to configure keyboard bindings. Fixes #403.
Fix aspect ratio/scaling for popout window
Read Wiimote Expansion port properly.

Technique from http://wiibrew.org/wiki/Wiimote/Extension_Controllers#The_New_Way
Parse Wiimote Classic Controller Pro buttons correctly.

There were what appeared to by typos from copy-paste of Nunchuk code,
and also the Classic Controller uses a bit value of 0 to indicate a
button is pressed.

I only had a Classic Controller Pro (not a Classic Controller or
Nunchuk) to test with.
IOHIDEvent.m: triggerEventWithPadNumber: use proper maximum.

If this is set to value, as it is before this change, then value often
(always?) is initialized to 0, and then when the trigger is actually
used, there is an assertion failure b/c the value (positive number) is
beyond the maximum (0).

This was occurring when using a Wii Remote with Classic Controller
Pro.
Support for new all new Wii Remotes with MotionPlus inside.

There are two types of Wii Remote at the time of writing: The
traditional ones and a newer variety that is more restrictive in how
one interacts with it. To support both, a few changes are required:

Discovery:

Newer Wii Remotes have a different minor device class than the older
ones, so a scan that simply looks for a particular major and minor
device class will miss at least one type of Wii Remote. To address
this, we scan for all bluetooth devices for 3 seconds, then check each
for a common prefix shared by the names of both types of Wii Remote
("Nintendo RVL-CNT-01" and "Nintendo RVL-CNT-01-TR").

Device Communication:

Historically, open-source Wii code has treated the Wii Remote like a
standard HID device and sent messages over the control channel with a
0x52 byte prefix, but unfortunately the newer Wii Remotes don't
receive messages sent like this. All Wii Remotes will accept messages
sent on the interrupt channel with a byte prefix of 0xa2, though, so
we change the code to use that.

To test this change, I paired 3 Wii Remotes simultaneously: One
Nintendo RVL-CNT-01 and two Nintendo RVL-CNT-01-TR. The -TR remotes
need to be disoverable by using the wrist strap to push the red button
on the back, while the non-TR one was made discoverable by holding
down buttons 1+2.
Wii Remotes: Illuminate LEDs based on pair ordering.

Historically when pairing two Wii Remotes, they would both have the
first LED illuminated. This is unlike most other software that lights
up different LEDs.

With this change, we illuminate the LED corresponding to the pair
order of the Wii Remote. I.e., the first Wii Remote gets LED 1 lit,
the second gets LED 2 lit, etc. If there are more than 4 Wii Remotes,
we wrap around, so multiple Wii Remotes will have the same LEDs lit.
Merge pull request #407 from adlr/expansion

Wii Classic Controller Pro support
OpenEmu activates itself when launching a game in fullscreen. (Fix #114)
Added display of 'processing' status to grid view. Still buggy right now, probably due to core data multithreading.
Adds OEToolTipManager to handle display of custom tooltips. Uses private api. Related to #302. Does not look exactly as we want it to.
Fix Wii Remote Nunchuk button handling.

The nunchuk button report uses 0 for pressed and 1 for released.
Add WiiU Pro Controller support. Joysticks are disabled right now as there must be something I'm missing
Merge branch 'nunchukbuttons' of https://github.com/adlr/OpenEmu into adlr-nunchukbuttons