Update error messages from push and update

Error messages now include model type for ease of debugging
[BUGFIX] Normalize typeKeys to always be camelCase

typeKeys must have a strong formatting convention, since they are used
for comparison in several spots of the code. Prior to this commit:

  * The container's normalized version of the factory name was set to
    the typeKey. This leaked the container concerns about name
    formatting up to Ember-Data, and to the user's interaction with
    API calls like `find('some-module')`
  * The typeKey property of a model class was allowed to pass into the
    code without normalization.

In general, for a developer to know which to pick of `find('some-car')`,
`find('someCar')` or `find('some_cars')` they had to understand which
resolver their container was using. This demonstrates a bad coupling,
and makes documenting Ember-Data exceedingly hard (we should not need to
mention a caveat about picking a resolver).

This commit normalizes typeKeys to always be camelCase, both those
returned by `typeForRoot` (for which the documentation has been
improved) and for those set on factories by `modelFor`.

From here on, `find('someCar')` should be considered the standard format
for multi-word model names.
normalizePayload only gets the payload

normalizePayload has been living a lie. It claims to be passed the model
type when called, but in often does not receive this argument (null is
passed instead). This only serves to confuse the use-case for
normalizePayload, and encourage its use when overriding an extraction
helper is actually the right choice.

This tradeoff, dropping the argument of type in all cases, means
normalizePayload can still be run over data added with pushPayload.
pushPayload knows nothing of which model is being pushed, and thus
cannot provide the type reliably.
Add a base fiddle for mocked data requests with Ember Data
Removed unused resolver from ManyArray.fetch
Do not cache model factories on meta, or on other model CPs

Relationships are hard. Ember-Data has been storing data about a
relationship on the meta value for that CP. CPs hang around though, and
as a result that data on the meta becomes a cache. For some details
about a relationship, this is fine.

If User has many Posts, and you use User via a container, it would cache
a reference to the Post factory. But if you then destroy that container,
the reference to Post still exists in the CP meta. Furthermore, if you
create a new container and use User and Post via that new container,
the cache factory value for Post will be that of the old container and
not the new container.

This only is a problem if you expect to have Post be a different factory
in each container. In ember-cli, MODEL_FACTORY_INJECTIONS are enabled.
This means all factories are extended before being returned by the
container. So every time you have a new container, you have a new
factory (though it looks and behaves the same).

This change gets rid of that cache on meta. Instead it creates a
function that accepts the store and meta, and returns the relationship
object expected throughout Ember-Data. Two alternatives were considered:

  1. Always check against typeKey instead of instanceof, but this felt
like a dodge of the real problem and would leave the issue for others to
find, or
  2. Create a new first-class relationship object, but this would
be a far more invasive change, and would impact much of the codebase
that the current relationship object has already leaked through.

Additionally, the types were being cached on model class-level CPs. For
this patch, those have simply been marked cacheable(false). A later
patch should refactor the CPs out of the way, or at least re-write their
consumers to expect a relationship object without the factory itself
already fetched.
Makes sure extractArray is normalizing each record in the array instead of trying to normalize the whole payload as an object.

This was causing `applyTransforms` to do the transforms in properties of the array instead.
Merge pull request #1953 from bmac/fix-extract-array-miguel

Makes sure extractArray is normalizing each record in the array instead ...
Use keyForRelationship in JSONSerializer's serializeHasMany method

- serializeBelongsTo uses the same already
Merge pull request #1954 from emberjs/JSONSerializerKeyForHasMany

Use keyForRelationship in JSONSerializer's serializeHasMany method
[BUGFIX] store.fetchMany should always return a promise.
Merge pull request #1955 from emberjs/fetchManyAlwaysReturnsAPromise

[BUGFIX] store.fetchMany should always return a promise.
Merge pull request #1942 from duereg/master

Removed unused resolver from ManyArray.fetch
Merge pull request #1941 from mehulkar/base-fiddle

Add a base fiddle for mocked data requests with Ember Data
Add package.json to built gem

`Ember::Data::VERSION` is defined by `package.json` since 7d7ccfa44.
Without thi file, ember-data-source couldn't resolve own version.
Merge pull request #1871 from duereg/patch-1

Update error messages from push and update
Merge pull request #1956 from tricknotes/fix-gem-version

Add package.json to built gem
Update README
Merge pull request #1952 from mixonic/meta-cannot-cache-factories

Do not cache model factories on meta, or on other model CPs
Do not presume returned data arrays support .pushObjects

Returned data will cannot be assumed to be an Ember array object. A test
should not pass in an Ember array as API response data.