fix(ngResource): don't convert literal values into Resource objects when isArray is true

[caitp]

Previously non-object literals would be thrown out of Resource responses with isArray===true, or otherwise converted into Objects (in the case of string literals). The reason for this is because shallowClearAndCopy iterates over keys, and copies keys into the destination. Iterating over String keys results in integer keys, with a single-character value.

Not converting non-objects to Resources means that you lose the ability to perform Resource operations on them. However, they become usable as strings, numbers, or booleans, which is important.

In the future, it would be useful to make these useful as Resources while still retaining their primitive value usefulness. (@rodyhaddad can you think of a way to do this? You're the master of ES5 valueOf, as far as I know :P)

Closes #6314

[rodyhaddad]

You can overwrite the valueOf of a given Resource instance, and make it return the primitive value. That would make the object take its original value when used with operators that don't work with objects (e.g. +).

But I believe it would create bugs that are hard to track for our users ("an empty Resource instance that sometimes behave like a primitive and has no data on it 😯 ") :

Maybe Resources can have hooks to handle non-object responses?

---

+1 for the issue this PR tries to solve though :-)

[caitp]

I don't think we can pretend Resource objects are primitives, since it wouldn't work when writing to them and stuff. It's probably adequate to just not convert them to Resources unless they're objects, since you probably aren't going to try to send off the primitives on their own.

But, someone else can think about that

[rodyhaddad]

We're using typeof item === "object" instead of isObject(item)

What if it the array is [null]?

With this PR, the resulting array contains an empty Resource object.
Do we want that? or do we want the resulting array to contain null too (breaking change)

[caitp]

its not a breaking change, it is already empty/not copying anything in (for key in null) { ... }). probably better not to get rid of it though

[rodyhaddad]

Currently if the response is:
['a', null],
it results in:
['a', new Ressource(null)] // empty resource (no id, so thing like $save act weird?)
This PR doesn't change that

I just want to be sure that it's the behavior we want. Maybe we want it to result in:
['a', null]
which would be a breaking change that's worth noting

[IgorMinar]

Not wrapping null into a resource instance sounds reasonable. We should add a test for it. Otherwise lgtm.