Preliminary client notifications

Well, this was interesting. Exposed a small number of issues..

 * Cannot use get_value immediately after set_value, though it indeed comes from the notification CHANGED event. This causes libbuxton to eat both segments, CHANGED, and STATUS.

 * get_notifications has to be non blocking. The only alternative is a reader thread and queue, which is ugly.

 * Due to data eating, we need to move to a totally nonblocking implementation throughout, with simulated blocking methods. This can be achieved by using a dispatch method to set various states and stored members, support callbacks, but use a mutex lock in the supposedly synchronous methods. This will be great for get_value, etc.

 * -For some incredibly strange reason, only the first registered notification consumer receives the notifications. Second consumer can still set, but receives no notifications. Looking deeper this seems to be an issue with the rather ugly LIST macros. Suggestion here is to replace with a properly managed BuxtonList (as seen in one of my previous pull requests). This is far cleaner and ensures it stays in the list, as well as properly maintaining the head.
Also my last implementation took into account William's comments about maintaining the list tail for speed.-

^ Last point is no longer relevant! I replaced the notification_list_item stuff with my own BuxtonList, its cleaner, faster, and works.