chore: Make list.rs non generic & simplify the code

[SemyonSinchenko]

Which issue does this PR close?

Closes #1114

Start of the discussion: comment in the PR1073

Rationale for this change

Spark supports only i32 indixed arrays but Comet attempts to support both ListArray (i32 indexed) and LargeListArray (i64 indexed). As a result the code in list.rs contains additional complexity that is not reachable and is not tested anyhow.

What changes are included in this PR?

Refactoring of the list.rs, ListExtract, GetArrayStructField and ArrayInsert now accept only ListArray instead of GenericListArray

How are these changes tested?

All existing tests.

[SemyonSinchenko]

@andygrove As you mentioned in #1073, it would be interesting to remove all logic related to LargeList and check if there is any regression. I did just that and all tests passed.

[SemyonSinchenko]

There is a valid argument against it:

The difference I think is that a LargeList can store more than Integer.MAX_VALUE entries in all rows in a single batch, so if you have multiple Spark rows all with the max num of rows supported, it wouldn't fit into an Arrow List array. That would probably need to be supported elsewhere, but it may be worth keeping the LargeList handling around in case that scenario is supported? And other DataFusion expressions might return a LargeList even if it doesn't come directly from Spark? Does the native Parquet reader ever use a LargeList?