Logical Device Support

cc/ @bencevans 

Changes:
- Changed [Listener](https://github.com/stephen/node-sonos/blob/logical-devices/lib/events/listener.js#L10) class to think in terms of "handlers" instead of "endpoints." This makes more sense because you might have multiple handlers for a given endpoints' events, so "client" code should think about handlers logically. I don't believe any previous code used these, but it could technically be considered a breaking change (API changed `addService`/`removeService` to be prefixed with `_`.
- Added `LogicalDevice` class. Takes in an array of Sonos devices that can be managed together (i.e. forms a group or stereo pair). This class currently supports group change for volume. The API between a `LogicalDevice` and regular `Sonos` device should be identical. (Commands that are only addressed to the coordinator (e.g. play/pause) are simply passed down to the underlying `Sonos` prototype.
- Added a `volumeListener` class to keep internal state on a `Sonos` object. Used by `LogicalDevice` to do volume changes (but not on other methods).

Missing:
- Lacks a search function. Will be addressed in separate 1.0.0 PR.
- Lacks group impl for `getLEDState`/`setLEDState`. Should be trivial (and also low pri..)
- Does not change the underlying `Sonos` implementation to use the newly cached volume state (should be address by separate PR)
Hmm, iirc Sequelize does something like...
```
new Sequelize().initialize().etc();
```
Which relies on promises. The current API here is:
```
new Sonos().initialize(callback);
```
Which is more or less the same thing, except using callbacks, not promises. 

My thinking is that we can automatically initialize for `Sonos` and `LogicalDevice` instances returned by a `search()`/"managed" sonos device, but leave calling `initialize()` up to client code if manually constructed (i.e. `new Sonos().initialize(...)`.