Introduce alternate syntax for in-line fragments

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](https://github.com/emberjs/data/issues/53#issuecomment-37097986) on [the epic thread that started this all](https://github.com/emberjs/data/issues/53):

``` javascript
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`.