Rethink `OperateOn` output length

[haberdashPI]

Though the current rule is convenient for signal padding, it leads to what are probably unexpected outcomes: e.g. x below is a finite length signal.

x = mix(sin,1,rand(10,2))

We need is for there to be some form of "weak" padding. This padding only applies when the signal is operated on in combination with another, longer signal.

[haberdashPI]

I don't like the "weak" padding solution. I like how numbers work, as infinite length signals. However, it is annoying to have them mix or amplify with the proposed scheme of weak padding. We would also need these values to have "weak" infinite lengths.

I could have two types of infinite length I guess... inflen and asneeded. The as needed signals would work the same as inflen except in the case of calling an operator.

The thing is, if we ever want mix above to be an infinite result, it's easy to generate.

mix(sin,1,Pad(rand(10,2),zero))

That seems easier to understand than this weird, special length value. So I actually think I'm not changing anything here.

[haberdashPI]

We can’t always know that a stream isn’t infinite. So we have to change this behavior.

Idea: allow for a property of signals (not lengths) called Extending. Extending signals are infinite but their length is excluded when determining the length of a result of OperateOn.

[haberdashPI]

We should give this property to numbers, and we an create Extend which is like Pad but has this property.

[haberdashPI]

I can simplify the MapSignal objects, and not have a padded_signals argument.

[haberdashPI]

The problem with the Extended proposal: it works coherently for the Extend method, that works how we want. Numbers however work a bit different, because we really want them to yield infinite values when they are the only thing present: or rather we want them to yield 0-dim objects that are lazily broadcast across the time dimension.