Refactoring VarName: new indexing scheme

[yebai]

At the moment, Turing internally stores and index parameters using two different naming schemes

{model_id, original_varname}:counter # VarInfo
original_varname  # Chain

This causes a lot of issues, e.g.

• Chain can't handle dynamic dimentionality [BNP] Bayesian Nonparametrics project #370 [Chain] flatten fails with different random variables in samples #386
• VarInfo ==> Chain is not reversible Save model and sampler as fields of Chain #269

These issues can be resolved together with a consistent naming scheme used by all data structures such as Chain, VarInfo and inference algorithms. One possible naming scheme is

@model mdemo(y) = begin
 #  {model_id, unique_scope_id, original_varname, indexing}:counter 
 #       counter increases everytime mdemo is called
   x ~ Normal   
   z ~ Discrete  
   for i = 1:z
       # counter increases for each loop iteration
       #      {model_id, unique_scope_id, original_varname, indexing}:counter 
       w ~ Normal  
   end
end

Both VarInfo and Chain can internally use unique_compiletime_id:counter as their index. At the same time, we can also support the following

c = sample(mdemo(y), alg)

# return all vars with the same unique_compiletime_id
c[:unique_var_id][counter]

# return all vars with the same name: x
#  note unique_compiletime_id may be different for different entries
c[:x]  

This indexing scheme supports stochastic control flows (e.g. conditional, loops). It can also support compositional modelling #139 since var names don't clash with each other even when mdemo is called by another model.

Related issues: #456

@trappmartin @xukai92 @emilemathieu

[yebai]

Ps. I have attempted to enumerate all clashing name cases. However, there might be cases that I'm not aware. Please suggest any special cases that can potentially break the proposed naming scheme.

[yebai]

For sanity checks, we might want to store the domain constraints of each parameter and verify them during replaying.

[yebai]

Closed by #965