Fix correctness of submodels that aren't inlined under SMC/PG

[penelopeysm]

Due to #2772, the following fails (unlike as described in the issue, you don't need to edit DynamicPPL code to trigger this: just putting @noinline in the body of the submodel is enough).

using Turing, StableRNGs, Test

@model function inner(y, x)
    @noinline
    y ~ Normal(x)
end
@model function nested(y)
    x ~ Normal()
    a ~ to_submodel(inner(y, x))
end
m1 = nested(1.0)
chn = sample(StableRNG(468), m1, PG(10), 500)
@test mean(chn[:x]) ≈ 0.5 atol=0.05

The reason is because the submodel evaluator function i.e. inner(model, varinfo, y, x) is not marked as produceable via Libtask.might_produce. That means that Libtask's IR transformation pass skips over the call to inner(...) completely, and any observations inside the submodel are lost.

Consequently, on the current release (v0.42.8), the chain above just samples from the prior, and the mean of x will be approximately 0.

This PR patches it by declaring that ANY function of the form f(::Model, ::AbstractVarInfo, args...) is produceable. This causes the test above to pass.

As described in the comment in the source, this seems overkill: if we mark more methods as produceable than are necessary, this can lead to performance slowdowns since Libtask has to transform more function calls.

The thing that allows us to use this hacky patch, though, is that there is pretty much only one case where anybody is calling a function with the signature f(::Model, ::AbstractVarInfo, args...) inside a DynamicPPL model -- which is the submodel case. There are other functions that have similar signatures, but none of them are likely to be called inside a model.

The other thing to note about this PR is that marking this generic method as produceable is not sufficient to handle submodels with keyword arguments, because for such submodels, extra methods need to be marked as produceable. Furthermore, it is not possible to statically determine this because the exact method that we need to target will depend on the number of keyword arguments (see TuringLang/Libtask.jl#197). In this case, it is therefore still mandatory for the user to use the Libtask.@might_produce macro themselves (which Turing re-exports).

All of this is mentioned in the patch notes.

[github-actions]

Turing.jl documentation for PR #2778 is available at:
https://TuringLang.github.io/Turing.jl/previews/PR2778/

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.10%. Comparing base (9be3ed5) to head (d6e4d95).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2778      +/-   ##
==========================================
+ Coverage   87.08%   87.10%   +0.01%     
==========================================
  Files          20       20              
  Lines        1309     1311       +2     
==========================================
+ Hits         1140     1142       +2     
  Misses        169      169              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[penelopeysm]

Closed in favour of #2780