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.
I'd prefer not to put a dependency for Google Play Services (wear or normal) in the core module.  There are some Android devices (e.g., [Google Glass](https://code.google.com/p/google-glass-api/issues/detail?id=176), some AOSP builds) that won't have Play Services for certain reasons.  I'd prefer to only include dependencies for canonical AOSP and open-source support libraries.  This means that there will be some duplicated code surrounding the `GoogleApiClient` (on this note - see https://github.com/OneBusAway/onebusaway-android/pull/199 - we're now using this for location too) and other classes.  If we start duplicating a lot of code between components we might want to pull out a separate Play Services support module.