…xing.

The current implementation is, essentially, a distributed hashmap from
integer keys to the list contents, mediated by each upstream worker starting
at a random value to minimize overlaps and emitting sufficient metadata to map
this onto the contiguous range [0, N). This provides optimal *random-access*
performance, but very poor *iteration* performance (essentially having to do
a key lookup for every advance, and as the keys are hashed and distributed
rather than clustered numerically, there is little to no amortiziation in these
lookups for adjacent items.

Given that most uses for List side inpupts are merely to gather a collection
of values (the user has no control over the ordering when materialized) and
the high costs of providing random access, this is probably the wrong tradeoff
for most pipelines.

This is an update-incompatable change and so has been guarded by the
update compatibility version flag. The old behavior can be explicilty
asked for via a new AsList#withRandomAccess() method.

…ault...

(I kept the name for ListViewFn2 just in case there are pipelines serializing it as data.)