Refactor Category to remove network & business logic methods

This is the model I'm suggesting we follow going forward.

CategoryService was created to contain all of the class methods originally tacked onto Category.  CategoryService requires an instance of NSManagedObjectContext to perform all of the Core Data calls.  Objects should really only be passed into CategoryService by NSManagedObjectID to prevent problems with thread locking.  Objects returned from CategoryService can be NSManagedObjectIDs - the calling code should understand the object is limited to the context used to create the service and should only safely access it accordingly.

If the calling code needs to perform the work on background context, it is responsible for wrapping the call in performWithBlock or performWithBlockAndWait.  Service objects are dumb.

CategoryServiceRemote wraps all of the remote calls.  It can receive NSManagedObjects as parameters since it's lifetime is limited to the method call in the Service class.  Remote classes are responsible for mapping parameters to remote calls.  Completion handlers should take parameters not tied to Core Data and let the Service class handle creation of new entities and mapping returned data to them.  Contexts are not saved in Remote calls, only the calling Service method can touch contexts.

The Remote class should probably take a Blog as a parameter to get the API and other default parameters until such time as we refactor Blog.