Introduce alternate syntax for in-line fragments

[slindberg]

Fragments are designed to be reusable and flexible, but that comes at the cost of a verbose API. For the simplest use cases, it should not be necessary to declare a new DS.ModelFragment class. This could be possible by introducing some sugar on top of the current API, which would allow for reuse/flexibility when needed.

@silvinci's proposed a concise shorthand syntax in his comment on the epic thread that started this all:

App.Customer = DS.Model.extend({
  // Shorthand for `DS.hasOneFragment`
  name: DS.obj({
    first: DS.attr("string"),
    last: DS.attr("string")
  }),

  // Shorthand for `DS.hasManyFragments`
  invoices: DS.arr({
    sum: DS.attr("number"),
    items: DS.hasMany("items")
  }),

  // Shorthand for `DS.hasManyFragments` that accepts 'primitive' type
  loginDates: DS.arr("date")
});

It should be trivial to auto-generate anonymous DS.ModelFragment sub classes in the DS.obj and DS.arr property helpers, however this syntax raises a few issues:

1. These fragments could not be created through DS.Store#createFragment, which means they would need to be created via literals proposed in #10 (or DS.FragmentArray#createFragment).
2. What serializers do anonymous fragments use? I doubt it is acceptable to be locked into using DS.JSONSerializer. Perhaps a default fragment serializer can be introduced that can be overridden in the container? Naming the generated fragment using a combination of the model type and attribute name seems wrong.
3. DS.arr and DS.hasManyFragments cannot be used interchangeably since passing a string to DS.arr would introduce ambiguity, e.g. is the string an attribute type or a fragment type? This may be a good thing.

The idea of anonymous model classes is a dubious one, however I cannot readily point to why. Another downside to this syntax is that it's not immediately obvious from the naming what the expanded form is, e.g. obj doesn't have readily apparent connection to hasOneFragment.

[knownasilya]

Yes please. Also why not allow using createFragment? Just add an id property

invoices: DS.arr('invoice', {
    sum: DS.attr("number"),
    items: DS.hasMany("items")
  }),

Then you can use createFragment('invoice'...