Add IndexingOnANonIndexedSeq rule to Linter

[JoshRosen]

Inspired by https://twitter.com/jshrsn/status/865677863646658560, this patch adds a new IndexingOnANonIndexedSeq rule which raises a warning when we see code which indexes on a Seq which isn't known to be an IndexedSeq subtype. The goal here is to make it easier to prevent cases where someone writes an O(n^2) loop by accident.

I'm opening this PR against my own fork rather than upstream because this is still an early draft which needs self-review and testing (plus I don't have time now to get it ready for full upstream standards, such as README documentation and examples, etc.; plus it might not be as generally applicable / useful outside of Spark's needs).

This rule should have prevented the following Spark bugs:

• [SPARK-20773][SQL] ParquetWriteSupport.writeFields is quadratic in number of fields  apache/spark#18005
• [SPARK-9952] Fix N^2 loop when DAGScheduler.getPreferredLocsInternal accesses cacheLocs apache/spark#8178
• [SPARK-17648][CORE] TaskScheduler really needs offers to be an IndexedSeq apache/spark#15221

For comparision, here is the same rule implemented in scapegoat: JoshRosen/scapegoat#1

[JoshRosen]

The idea behind ignoring Seq.apply(<literal>) was to prevent this rule from masking the UseHeadNotApply rule for things like x(1).

[JoshRosen]

Running this on Spark turned up a lot of cases. After manual inspection it looks like most are non-issues, but I may have spotted some bad ones:

• In https://github.com/apache/spark/blob/bbd8d7def149e787a33ed0decf332d33c593e93c/sql/core/src/main/scala/org/apache/spark/sql/execution/stat/FrequentItems.scala#L91, we call Seq.tabluate, which ends up returning a List:

  scala> Seq.tabulate(100)(_ => 1)
  res3: Seq[Int] = List(1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1)
  

  This is then passed into an RDD.aggregate call and I think this will continue to build up Lists. We iterate over the fields of those lists, so I wouldn't be shocked to find that we're getting O(n^2) when performing FrequentItems on a wide schema. However, this doesn't seem to actually be a problem in practice because most of the time in that loop is spent in hashmap lookups.

• In RDDConversions there are cases where we index into a Seq of conversion functions: https://github.com/apache/spark/blob/bbd8d7def149e787a33ed0decf332d33c593e93c/sql/core/src/main/scala/org/apache/spark/sql/execution/ExistingRDD.scala#L41. We really should ensure that these are arrays because we'll get horrific performance in case productToRowRdd(... List) is called.

Those are just the first two that jump out to me from skimming the results; there may be others which are less obvious.