VNT docs: more things to elaborate on

#1204 adds a LOT of new docs on VarNamedTuple. There are still things I want to cover, but haven't. This issue is for me to list these things.

user-facing

• Inflexibility to change shape/type of array once set. Impacts on DynamicPPL model specification. This is the main user-facing one.
• Performance implications. What you can do to make your model faster. Concrete examples.
  • Since a shadow array is created for every x[i], you should only create an array x if you intend to use all (or at least most) of its elements on the LHS of tilde. Doing something like x = zeros(1000); x[1] ~ Normal() means that VarInfo will contain 999 useless masked elements. This encourages separation between "things I need for the function" and "things I need for the probabilistic model", which is good anyway.
  • Preserving type stability by using arrays with concrete eltypes.

dev

• Conceptual similarities between handling VarInfo and AD / sparsity detection. Differences (AD can hook into every statement in the function, VarInfo can only hook into tilde-statements -- which leads to the above restriction on size-changing arrays).
  • Interesting that info about structs in the model are lost. They are just replaced with VNTs inside the VarInfo. Similar to Mooncake tangents, as I pointed out way back when.
• Handling PrefixContext & submodels
• Edge cases: where do things break down (see 'Known issues with VNT' issues I opened)
• Edge cases we do handle and how we handle them: x[1:2][1] and x[1:2][2] is a good example
• ArrayLikeBlocks. Markus wrote some stuff, but I want to add examples and code snippets.
• Usage inside DynamicPPL: ValuesAsInModelAcc (stores plain values) vs. VarInfo (stores TransformedValue things). Differences in keys. See also https://github.com/TuringLang/DynamicPPL.jl/issues/836.
• Probably more, I can't think right now because my brain is legitimately fried.

Review the VarNamedTuple documentation added by #1204 and the linked DynamicPPL issue #836 before choosing a focused section. Use the unchecked user-facing and developer topics as the scope, especially array shape changes, performance, PrefixContext, submodels, and known edge cases. Done means adding concrete explanations and examples for an agreed subset of these topics.