Issue 181 wear support

@barbeau This is getting quite large so I figure I'll take a break and get some feedback.

I would like to get an app on the wearable which has 2 use cases:
1.  Browses starred stops.
2.  View ArrivalInfo for a stop.

Designwise, I created a long running ```NodeService``` on the device which is the sole interface for the wearable to the Oba data.

The wearable fires messages to the ```NodeService``` to request data synchronization updates.

The NodeService will then update the Wearable datastores with the requested data updates via Wearable.DataApi calls.  The source of these data updates can be direct calls to the ObaApi or data from the ObaProvider, depending on the use case requirements.

For now I've only implemented the first use case of retrieving Starred Stops.

Implementing a polling ArrivalInfo hook into the NodeService would be next on my agenda.

I tried to document any areas I feel required extra inspection with todo tags.
>How about for acceptance criteria on #6 we make a note that the wearable module should send sorted data based on the user preference on the device?

Do you mean that the wear app on the watch would use the same sorting method as currently selected in oba-android on the device?  If so, I think this is probably good as a default setting, but I would imagine for quick wear interactions (without the main app/device in the loop) we'd also want the ability to change sorting method on Wear based solely on interactions with oba-wear app.

Yet another sorting option would be by proximity - this is something I plan to implement as part of the "Nearby" UI section in oba-android, with one of the primary use cases being by users with visual impairments (see https://github.com/OneBusAway/onebusaway-android/issues/22).  

How does location work on Wear?  Does it grab locations from location providers on the main device?  If we do sorting by proximity on Wear I would think it would need to be based on the NETWORK_PROVIDER to be fast enough to be useful, if a GPS_PROVIDER location isn't readily available.  That can severely limit accuracy of results if WiFi location isn't active (since you fall back to cell tower location), but its probably a good trade-off.