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
Remove a 'fix' that is causing other problems
Merge branch 'master' into adlr-nunchukbuttons
Remove debugging function
Code clean up.
resolve logging about class being there more than once

OECUESheet is already being linked in the base framework, which the
main app links against. remove the second linkage.
Removing the old Wiimote code.
Remove unused imports from dead files
Hide the cursor when entering full screen