Refactoring Glue Code

[ParadaCarleton]

Issue for keeping track of the process of removing glue code that is made unnecessary by the new simple varinfo.

[devmotion]

VarInfo isn't removed, so we still need all VarInfo code, don't we? We rather have to add some SimpleVarInfo code as well if it is added, or preferably generalize the code to AbstractVarInfo.

[torfjelde]

Nothing is made unnecessary by the new PR, and so AFAIK there's no glue-code that should be removed.
We simply have to update some functionality to be compatible with immutable implementations, where most of these can be found in #1726 .

[ParadaCarleton]

@yebai @cpfiffer did I misunderstand what we were talking about yesterday?

[yebai]

It should be refactoring the glue code, I think. We would like to create an interface between Turing-AbstractMCMC that can be shared by more samplers. For example, AdvancedMH and AdvancedHMC can share the log density interface. At the moment there is a lot of redundancy in the glue code which we want to reduce via careful refactoring.

[torfjelde]

For example, AdvancedMH and AdvancedHMC can share the log density interface.

So this doesn't have anything to do with SimpleVarInfo, but rather it's related to TuringLang/AbstractMCMC.jl#85, in particular this comment: TuringLang/AbstractMCMC.jl#85 (comment)

I've begun working along these lines here: TuringLang/AbstractMCMC.jl#86.

[yebai]

Closed in favour of #1904 where we will make an effort to reduce redundant glue code by using a cleaner VarInfo design from DynamicPPL.