Retries the change in #2196 , which were reverted in #2394.

This "simplification", was tried before and rolled back because it caused some Memory Leaks. Inspecting a heapdump, we saw that the leaks were caused by the compilation creating many objects of type Bind, BindBind, or DelegateBind, in which the step (the pull on the left of >>=) was just a terminal. To avoid this problem, we add a "smart constructor" method bindView, used when creating a Pull by binding a Pull with a View. This constructor, instead of always creating a new object, applies the "continuation" function directly. This is admisible during compilation.

Edit: one consequence of directly calling the cont method, to avoid accumulating the DelegateBind objects, is that the tailrecM method of the Monad instance for Stream was no longer stacksafe. We could cause a stack overflow due to the long chain of recursive calls to the method cont going up the chain of BindBind objects. To avoid this, we extract a loop (tail-recursive method) to perform this simplification.

One problem, however, is that this seems to cause one test on the MonadError laws for Stream to fail, the stack-safety of tailRecM. However, when we run the code of the stack-safety test, using a different runtime, it seems to pass.