[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.
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.
Merge pull request #1939 from mixonic/do-not

Do not presume returned data arrays support .pushObjects
Merge pull request #1895 from mixonic/normalizeTypeKeys

[BUGFIX] Normalize typeKeys to always be camelCase