fix(filterFilter): correctly handle deep expression objects

Previously, trying to use a deep expression object (i.e. an object whose properties can be objects themselves) did not work correctly. This commit refactors `filterFilter`, making it simpler and adding support for filtering collections of arbitrarily deep objects.

Closes #9698

---
<sub>
BTW, I used "non-IE8" stuff (like `Array.prototype.some/every`) for the sake of conciseness and clarity, so this is not directly back-portable to 1.2.x. If there is interest, I can create a IE8 compatible version (using `for-loops` etc).
</sub>
@caitp:
My patch does indeed not care about inherited properties (only own properties).

Checking inherited properties (either on the items or on the expression object) is not documented, so it is debatable if it is a feature or a bug :smiley_cat:.

That said, since we support setting a function as expression (whereby the function is called with the item as an argument and the (boolean) result determines if it belongs to the `filtered` list or not), if we want to properly support deep expression objects we should handle function properties in a similar way. Explaining with an example (this is what my patch does):

```
var items = [{
    name: 'George',
    role: 'SuperDuperAdmin'
}];
var expr = {
    name: 'G',
    role: function (val) { return /admin/i.test(val); }
};
console.log($filter('filter')(items, expr).length);   // Prints: 1
```

This is how I think is more consistent (but there is a good chance you might think otherwise :smile:).

--
In any case, I don't really like taking into account inherited (enumerable) properties (neither on items nor on the expression object). It feels like it is mostly going to lead to unexpected results. If anyone wishes to do it though, they can use a custom comparator or expression function.

---
Additonally, what the current implementation does is convert expression `'some string'` to `{$: 'some string'}`. IMO, passing a string should **not** be affected by inherited Object properties (just because we choose to convert it to an object internally).

---
Finally, let me point out that the current implementation **does** take into account inherited properties on the expression object, but **ignores** inherited properties on the items (which seems at the very least inconsistent).