Refactor Settings update

@Jonahss settings changes touched off a 31 message exchange of chunky emails between Jonathan and me.  He helped me better understand Jonah's changes within the context of Node.  There were two major results from that discussion:

1. I see now that Jonah did all the right things; and,
2. I believe that my concerns can be resolved by refining Jonah's approach rather than supplanting it.

As I worked through the code with jlipp's help, the refactoring I did looked more and more like Jonah's solution.  However, I've been able to simplify things in several ways:

1. I encapsulated all the settings-related logic in the DeviceSettings object. This allowed me to remove the repetitive references to "get/updateSettings" from the various devices.
2. Encapsulation also helped me make updating settings more straightforward.  There's no need to worry about when to use `settings.update` vs `settings._settings`. There's only `settings.set` (well, there is a non-obvious way using `get`, but I won't get into that). 
3. In roughly the same amount of code that Jonah had written for DeviceSettings, I was able to provide the same functionality without using the EventEmitting class or Q or any other library.  The code I have works very similarly to EventEmitter, but it's less abstract, provides the functionality we need and nothing more, and requires a lot less code in aggregate.

Take a gander and let me know.  I'm hoping it's an "everybody is happy" solution. 
I should say tho, I think we should sketch out, if we haven't already, where settings is going to live.  Right now it's device-specific, which is why I assumed a single listener.  If other components are listening too, then it shouldn't be a device member.  I think we should make that call soon and in a formal way or else things are going to get screwy.