Change 2nd type parameter of stream to support unbounded streams

[jclark]

At the moment, the iterator for stream<T,E> is of type

    abstract object {
       public next() returns record {| T value; |}|E?;
    }

Note the ? in the return type of next.

This issue changes it so that the 2nd type parameter represents the completion type of the iterator, i.e. stream<T,C> is

    abstract object {
       public next() returns record {| T value; |}|C;
    }

where C would be a subtype of error?.

This allows us to represent an unbounded stream as type stream<T,E> where E is a subtype of error rather than error?. A function like toArray would then not be allowed on an unbounded stream.

This is a change to #406.

[jclark]

Our existing @typeParam annotation isn't quite powerful enough to capture the type of stream:toArray. It might seem like you could write:

function toArray(stream<Type,ErrorType?> stm) returns Type[]|ErrorType;

But this isn't quite right, because stream<T,error> is a subtype of stream<T,error?>, so this would allow you to pass an unbounded stream. It would also not be right to say:

function toArray(stream<Type,()> stm) returns Type[];

because that wouldn't allow a bounded stream that might return an error.

When the lang library does:

@typeParam
type XType X;
public function foo(XType t) returns XType = external;

X is the upper bound on the type parameter XType i.e. the type parameter can only be instantiated with a type T that is <= XType (i.e. with a subtype of XType). But for toArray what we need is a lower bound on the type, where the lower bound in this case is nil i.e. that it can only be instantiated with a type T such that () <= T. This is a lower bound that is in addition to the upper bound of error?.

So we will need to devise a way to represent that with an annotation in lang lib.

[jclark]

We can deal with fixes to @typeparam in #187: we may actually have this problem already with functional arguments.

[jclark]

We have the problem for stream:reduce already.

[jclark]

I made the new functionality for @typeparam into a separate issue #457.