[SPARK-3247][SQL] An API for adding data sources to Spark SQL

**Work in progress - APIs may change**

This PR introduces a new set of APIs to Spark SQL to allow other developers to add support for reading data from new sources in `org.apache.spark.sql.sources`.

New sources must implement the interface `BaseRelation`, which is responsible for describing the schema of the data.  This base relation must also implement at least one `Scan` interface, which is responsible for producing an RDD containing row objects.  The [various Scan interfaces](https://github.com/marmbrus/spark/blob/foreign/sql/core/src/main/scala/org/apache/spark/sql/sources/package.scala#L50) allow for optimizations such as column pruning and filter push down, when the underlying data source can handle these operations.

By implementing a class that inherits from RelationProvider these data sources can be accessed using using pure SQL.  I've used the functionality to update the JSON support so it can now be used in this way as follows:

```sql
CREATE TEMPORARY TABLE jsonTableSQL
USING org.apache.spark.sql.json
OPTIONS (
  fileName '/home/michael/data.json'
)
```

Further example usage can be found in the test cases: https://github.com/marmbrus/spark/tree/foreign/sql/core/src/test/scala/org/apache/spark/sql/sources

There is also a library that uses this new API to read avro data available here:
https://github.com/marmbrus/sql-avro

To be clear they will always be resolved here (or the analyzer would have thrown an exception).  I just usually don't use AttributeReference in type signatures so as to hide their implementation details.

You raise some good points though, and are making me reconsider an earlier design where we don't expose `Attribute` or `Expression`.  Instead we have an interface like this:

Attributes are `String`. This can just be `attributeName`.  We can possibly also support `attributeName.fieldName` (or  maybe even `attributeName[0]`?).  The planner will default to just pushing down full attribute projections, but the developer can override methods to turn on the more advanced projections.

For filters we define a simple set initially that we can add to as we go:

```scala
case class EqualTo(attribute: String, value: Any)
```

Pros: Easier to make binary compatibility promises.  Users don't have to handle `a = 1` and `1 = a` any more.  Does not expose catalyst.
Cons: Users have to deal with string parsing for complex projections.  Expressions pushed down are now are limited to those we decide to write duplicate code for.