Fix a bug with indirect produce calls in a loop

[mhauru]

We had a bug where if a function had a produce call in it, and was called multiple times in a loop, the position counter was not being reset as it should have. For instance, here's the new test introduced in this PR:

        produce_wrapper(x) = (Libtask.produce(x); return nothing)
        Libtask.might_produce(::Type{<:Tuple{typeof(produce_wrapper),Any}}) = true
        function f(obs)
            for o in obs
                produce_wrapper(o)
            end
            return nothing
        end

        # That the eltype of vals is Any is significant for reproducing the original bug.
        # Unclear why.
        vals = Any[:a, :b, :c]
        tt = Libtask.TapedTask(nothing, f, vals)
        @test Libtask.consume(tt) === :a
        @test Libtask.consume(tt) === :b
        @test Libtask.consume(tt) === :c
        @test Libtask.consume(tt) === nothing

Before this PR, what would happen here is that on first consume call we would hit produce in produce_wrapper, and produce_wrapper would set its position counter so that when it's next called, execution continues from after the produce call (which has been turned into a return ProducedValue(x)). On second call to consume execution would continue from there, and produce_wrapper would return. So far so good. But then f would call produce_wrapper again, but its position counter would still be stuck saying that execution should continue right after the produce call. Thus the above test used to fail with

   Evaluated: nothing === b
   Evaluated: nothing === c

This came up in #190 after the immediate issue crashing issue was fixed.

[github-actions]

Libtask.jl documentation for PR #192 is available at:
https://TuringLang.github.io/Libtask.jl/previews/PR192/