Introduce buildURLForHasMany hook

**Not ready for merge**

This introduces a new hook, `buildURLForHasMany`, to address the issues discussed in #2162.

This commit slightly changes the behavior of relationship resolution, but I've tried to keep the changes as unobtrusive as possible.

Specifically:

1. If a relationship is provided as an array of IDs, or `null`, the adapter's `findMany` hook will be called (after filtering out already-loaded records).
2. If a relationship is provided via `{ links: { relationshipName: '/foo' } }`, the value (usually a URL) will be passed to the adapter's `findHasMany` hook.
3. If a relationship is not provided (i.e., it resolves to `undefined`), then the adapter's `buildURLForHasMany` hook will be called. The value returned from that hook will be passed to `findHasMany`, as though it were provided in the `links` object.

Implementation was relatively straightforward, but the feature does raise some questions.

Namely, what should the default serialization be for `hasMany` relationships? We have three common representations for inbound JSON: inline array, `links` URL, or implicit URL generated by the adapter. Applications may mix and match two or more of these forms. What should we send back to the server when the record is saved?

The easy answer is: use the payload provided by the server as a heuristic. If the relationship is specified as an inline array of IDs, send that back. Otherwise, if the relationship is a URL (implicit or explicit via `links`), send nothing.

However, this approach falls flat when we consider the case of client-created records, which may be created and saved before we ever see an exemplar payload from the server. Additionally, many APIs send JSON different than what they expect to receive during a save.

Finally, what happens when a has-many relationship is specified by a foreign key on the belongs-to side? If a `Post` has many `Comment`s, and the contents of the `comments` ManyArray is populated by loading `Comment` records that have a `post_id` field, the `Post` payload will not have a `comments` field, which will trigger the `buildURLForHasMany` hook. I remain unsure how to reconcile this hook with future SSOT plans.

We could disable the `buildURLForHasMany` hook in the case that we see a foreign key for the relationship, but that means that load order affects the way relationships are resolved. This feels both confusing and difficult to debug.

Ultimately, the more I try to untangle this problem, the more I believe that we want a DSL for concisely expressing serialization rules, without requiring users to write their own custom serializer for these common cases.
[] or Ember.A