[osx] - fix issues with turning off/on tv when playback is paused

[Memphiz]

This fixes issues which users pointed out when turning off the amp or tv over night and try to continue where left of on the next day.

This change does the following

1. In ActiveAE there was a race condition when lostdevice (from windowing) occured with devicechanged callbacks (something like that i think :) ).
2. When we open the default device in the osx sink we need to query the device from CoreAudio instead of using our maybe outdated deviceid in the deviceslist (this is needed because in some constellations we only get windowing callbacks - but not devicechange callbacks rom osx).
3. The windowing code that fires OnDeviceLost and OnDeviceReset callbacks had a flawed logic. Now that those callbacks are used by ActiveAE those issues resulted in AE-Sleep-Of-Death - this needed a tiny refactor and fix

The last one looks a bit ugly in the diff but it is really easy what it does:
a. Adds a timer which is started whenever osx tells us "lost device"
aa. that timer is canceled when we get a proper "device reset" callback from osx
ab. if this is not the case the timeout of this timer will fire that callback (after 3secs with lost device) - and so wakes up AE again.
b. The callbacks we fire are refactored into 2 methods which are dumb (not checking flags or anything)
c. The logic of when those callbacks are called is completely in the "DisplayReconfigured" method
d. In addition to the kCGDisplayBeginConfigurationFlag and kCGDisplaySetModeFlag flags we also fire the onresetdevice callback when flags == 0. This is something which is not documented in Apples API but it is definitly happening (verified with a user)
e. Before this we only fired onresetdevice when there was a valid screen given in the callback from the os. But this assumption is not true. Because when the tv is turned off osx calls us without valid screen. In that case we still need to fire the onresetdevice for AE - else the engine never wakes up again.

Lot of text - hopefully it helps in understanding what this does - and that it is really needed for gotham :)

The bug hunting can be followed here:

http://forum.xbmc.org/showthread.php?tid=185395

Thx to repstein and gigantur who really did a great job in providing logs with a dozens of testbuilds over the last weeks for tracking the issue down (and having a response time which was only a couple of hours each time!).

Also thx to @FernetMenta who did a great job in interpreting that log files and finding the race and its fix.

[t-nelson]

@Memphiz Can you ping whoever needs to review this please?

jenkins build this please

[Memphiz]

@jmarshallnz and @davilla

[Memphiz]

@jmarshallnz and @davilla

[davilla]

ok

[t-nelson]

@jmarshallnz's button