starlark: add maxAlloc guard to list, sorted, enumerate

[YuvalFradkin1]

list(), sorted(), and enumerate() preallocate a backing slice using
Len(iterable) as the capacity with no upper-bound check. When called
with a large range() value (e.g. list(range(4611686018427387904))),
the resulting make([]Value, 0, 2^62) overflows and the Go runtime panics:

panic: runtime error: makeslice: cap out of range
go.starlark.net/starlark.list(...)
starlark/library.go:689

The panic is unrecovered and kills the host process. Any application
evaluating untrusted Starlark is affected.

The *Repeat helpers in eval.go already define and enforce maxAlloc=1<<30
for string/bytes/tuple repetition. This PR applies the same guard to
list(), sorted(), and enumerate().

Fixes: https://issuetracker.google.com/issues/499639516

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[adonovan]

Thanks. The code changes here look fine to me as a means to prevent accidents, but I fear this is at best a band-aid covering the most trivial ways in which it is possible to cause the interpreter to allocate too much memory. A creative adversary can easily find more complicated ways to do it, and I think it's unlikely that there will be a systematic way to avoid such problems by handling Go OOM conditions. (Even if all allocations performed by the interpreter used a different allocator, application-defined built-in functions would not.)

That said, the iterable returned by range does make it particularly easy to turn a large number into a large allocation. We should probably also address these operations which materialize an iterable sequence: tuple, reversed, zip.