Reduce getCurrentState interval frequency to fix performance issue

This reduces the interval frequence for `getCurrentState` in
SpotifyRemoteServer from every 250ms to every 500ms.

Using an AppleScript every 250ms seems eat up up a lot of CPU power. The
`coreservicesd` process on OS X was responsible for 13-15% of total CPU usage
(according to `Activity Monitor.app`).

With this fix in place (polling Spotify only every 500ms) the `coreservicesd`
CPU usage goes down to 7-10%.

In order to keep the snappiness of the client interface, the connected sockets
now manually trigger `getCurrentState` on `volumeUp` and `volumeDown` events,
and trigger `getCurrentState` and `getCurrentTrack` on `next`, `previous` and
`playPause` events.
Test SpotifyRemoteServer listening to socket events

This adds test for SpotifyRemoteServer's behaviour regarding sockets event and
asserts what SpotifyRemoteServer does when such an event is triggered.

I had to add some simple `on` and `trigger` stubs to the socket stub in the test
suite. Also, the spotify methods that get called on certain events are stubbed
in each test.

The tests assert that SpotifyRemoteServer really reacts to socket events by
emitting the current state or current track.

I also changed the test suite to use `server.stopIntervals()` in each test
(after the assertions) so they don't interfere with other tests making
assertions about the call count of certain methods that get called in intervals.
Remove debugging code and use 'original' instead of 'old' as stubbing prefix in tests
Merge pull request #4 from rmehner/reduce_state_interval

Reduce getCurrentState interval frequency to fix performance issue