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.
There were some dependencies that were getting pretty deep once I started refactoring out the UI components (such as ListAdapter) so I abandoned that effort to limit the scope of the request.

As far as moving it into the core module, I was considering that but after some thought decided against it.  The wearable does not have a local data store, it's data is derived purely from the ```Wearable.DataApi```.  So it would not make sense to have that logic on the wearable app since the wearable has no SQL functionality built in.  I did adjust the visibility of some of the constants so the NodeService on the device had access to them (the various ```KEY_XXX``` values).  We could refactor these constants out into a separate constant file in ```util``` I'm not familiar enough with the architecture to say whether we get much value add from doing this or not, but I'll defer to your decision on that.