[BUGFIX] Use declared mapping during serialization, even if keyForAttribute or keyForRelationship are defined

**TL;DR:** The `attrs` mapping feature now works for serializing data.

- - -

As you know, we're able to "map" an Ember Data attribute key to a completely different one that a backend expects by doing the following:

```js
var PostSerializer = DS.RESTSerializer.extend({
   attrs: {
    name: 'title'
  }
});
```

The method responsible for this mapping during normalization is `JSONSerializer#normalizeUsingDeclaredMapping()`, which performs this mapping on both regular attributes & related attributes (`belongsTo`, `hasMany`).

#### There are a few problems on the serializing side: ####

1. If `keyForAttribute` is defined, it will clobber the mapping during serialization for regular attributes. (41c4a0bfd773c51080cd5e1d017f339d4ece6b68)
2. *There is no mapping for `belongsTo` or `hasMany` attributes!* (a979c52acfeaba076453194403f8f645de4d0c4f)

This Pull Request fixes those two issues, allowing for true bi-directional mapping (serialization and deserialization/normalization) as one would assume. If `keyForAttribute` or `keyForRelationship` is defined, they're ignored for the explicitly mapped attribute. Consider this example:

```js
var ApplicationSerializer = DS.RESTSerializer.extend({
  // backend needs all keys to be snake_case
  keyForAttribute: function(attr) {
    return Ember.String.decamelize(attr);
  },
  keyForRelationship: function(attr, kind) {
    return Ember.String.decamelize(attr);
  },
});

var PostSerializer = ApplicationSerializer.extend({
  attrs: {
    // the backend requires the Post.name attribute to have a special serialized key,
    // different from the backend's own convention of snake_casing serialized keys.
    name: 'posttitle'
  }
});
```

Integration tests have been added for regular, `belongsTo`, and `hasMany` attributes favouring the mapping over `keyFor*` hooks.