[BUG] Improve ORC reader performance with list columns and high row counts

[GregoryKimball]

Is your feature request related to a problem? Please describe.
We observe degenerate performance with the ORC reader with list columns when the row count is high. The Parquet reader does not have a similar issue.

Here is a cuDF-python code snippet for reproducing and profiling this issue:

    for num_rows in [1_000, 50_000_000]:
        df = cudf.DataFrame({'a': [[1]]*num_rows})

        df.to_parquet('/raid/tmp/tmp.pq')
        df.to_orc('/raid/tmp/tmp.orc')

        with nvtx.annotate(f'pq {num_rows}', color="blue"):
            t0 = time.time()
            df2 = cudf.read_parquet('/raid/tmp/tmp.pq')
            t1 = time.time()        

        print(f'parquet (numrows {num_rows})', t1-t0, 'seconds')

        with nvtx.annotate(f'orc {num_rows}', color="green"):
            t0 = time.time()
            df2 = cudf.read_orc('/raid/tmp/tmp.orc')
            t1 = time.time()

        print(f'orc (numrows {num_rows})', t1-t0, 'seconds')

With cuDF 23.06 and on my Epyc-A100 workstation, this script yields the following execution times:

parquet (numrows 1000) 0.0058746337890625 seconds
orc (numrows 1000) 0.003462076187133789 seconds
parquet (numrows 50000000) 0.012792587280273438 seconds
orc (numrows 50000000) 1.6445508003234863 seconds

Note how the Parquet and ORC times are similar for 1000 rows, but ORC is 100x slower for the 50M row case.

Nsys profiling shows that the bulk of the extra time is spent in a call to generate_offsets_for_list.

We missed this degenerate performance case previously because our benchmarks focus on wide tables with relatively large lists, rather than tall tables with short lists.