Even more false positives with no-array-prototype-extensions rule

[simonihmig]

On top of #1534, #1537 the rule also (IMO falsely) triggers when using methods of EmberArray, but not implicitly through prototype extensions (which is what this rule is trying to avoid AFAIU), but also when the EmberArray has been created explicitly, like in these cases:

• A([...]).uniq()
• blog.comments.toArray() (when blog is an ember-data model with a hasMany relationship - which also uses the Enumerable mixin)

While those cases maybe should be avoided in new code, they are not in any way deprecated (AFAIK), and as said above do not relate to prototype extensions, so they seem to be false positives here!

[bmish]

Yes, this is a false positive because it should be fine to use Ember array classes (EmberArray, MutableArray, ArrayProxy, fragmentArray from ember-data, others?) directly without relying on the prototype extensions.

We should be able to reduce false positives here by checking for simple cases where the object is created with A() or otherwise initialized to one of these Ember array classes. However, there will unfortunately be situations where the lint rule can't know what an object was initialized to (e.g. a function parameter, something imported from another file, etc).

[bmish]

Just to spell out one potential heuristic we could add for this related example:

async _fetchCategories(query) {
  const response = await this.store.query('connect/category', query);
  return response.toArray(); // false positive
}

class MyClass {
  async _fetch(query) {
    const response = this.store.peekAll('foo-bar', query);
    return response.toArray(); // false positive
  }
}

class MyClass {
  async _fetch(query) {
    return this.store.peekAll('foo-bar', query).then(response => response.toArray()); // false positive
  }
}

If a variable initialization comes from this.store, then we could assume it's Ember Data related and ignore it.

We should also call out in the doc any known false positives that we can't solve.