Update ObjectiveRelation methods to be more descriptive

Entity is usually used to describe an NSEntityDescription, so let's use
ManagedObjectClass, instead.

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Relationship relation builders

Adds support for -[NSManagedObject relationWithName:], which returns an
ObjectiveRelation for to-many relationships that have an inverse
relationship that can be introspected.

These relations will forward selectors to the original (mutable) set
where applicable. E.g.,

  [[person relationWithName:@"employees"] addObject:employee];

If the dynamic property defined for one of these relationships is of
type id, it will return an ObjectiveRelation, instead:

  @interface Person : NSManagedObject
  @property (nonatomic, strong) id employees;
  @end

  @implementation Person
  @dynamic employees;
  @end

  Person *person = [Person find:@"firstName = %@", @"Stephen"];
  // Fetch through relationship
  [person.employees where:@"firstName = %@", @"Marin"];
  // Create through relationship
  [person.employees create:@{@"firstName": @"Dave"}];

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Consistency

This project appears to prefer listing properties in the following
order:

 - readonly/readwrite
 - assign/weak/strong/retain/copy
 - atomic/nonatomic

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Whitespace adjustments

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Expose .fetchedObjects on relations

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Consistency

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Prefer synthesis

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Expose fetchRequest (and fetchedResultsController)

In exposing NSFetchedResultsController we need to better manage the
library's iOS and OS X interface separation.

Signed-off-by: Stephen Celis <stephen@stephencelis.com>
Make ObjectiveRelation stronger

Caveats? This removes some (magic), id-based functionality, including:

 - Calling NSArray methods directly on ObjectiveRelation objects.

     // This
     [[Person all] map:^(Person *person) { /* ... */ }];
     // Becomes this
     [[Person all].fetchedObjects map:^(Person *person) { /* ... */ }];
     // But this is still fine (because of NSFastEnumeration)
     for (Person *person in [Person all]) { /* ... */ }

 - Calling NSMutableSet methods directly on ObjectiveRelation objects.

     // This no longer works
     [person.employees addObject:[Person create:@{@"firstName": @"Marin"}]];
     // But we have a better helper, so it's OK
     [person.employees create:@{@"firstName": @"Dave"}];

Other considerations include whether we want to expose ObjectiveRelation
objects directly, or an ObjectiveRelation protocol:

  // This
  ObjectiveRelation *record;
  // Or this
  id<ObjectiveRelation> relation;

They behave, basically, the same, as the ObjectiveRelation class is a
direct subclass of NSObject, and the ObjectiveRelation protocol would
enforce the same strict typing.

Signed-off-by: Stephen Celis <stephen@stephencelis.com>