[Debuginfo] Emit artificial nested typedef representing generic params on MSVC - #165267

PDB has no node with which to represent generic parameters (i.e. template args, in LLDB parlance). This has resulted in playing with strings to a degree that I'm not happy with. It's finicky and error-prone and LLDB's type lookup behavior isn't even all that reliable in the first place. The current handling uses infallible methods when it can, but there's still issues now and then.

Part of the issue is that, especially for container types like Vec (which are what want visualizers the most), the only place the generic tends to show up is PhantomData... in another generic param, so still unreachable.

This patch takes each generic T and creates an empty static field of type T (e.g. static T GENERIC_ARG_0), that way they're easily accessible from the visualizers via valobj.GetType().GetStaticFieldWithName("GENERIC_ARG_0").GetType().

Worth noting, we use a similar trick for enums to encode their discriminants and variant names

That said, this is a pretty heavy-handed way to do this. Technically, the only place this is "necessary" is when the generic is only accessible via PhantomData (e.g. Vec). We could absolutely gate the static field generation by is_phantom_data() to NOT output so many fake static fields. The one extra problem with that is that LLDB omits 0-sized fields (including PhantomData) when creating structs with PDB debug info (llvm/llvm-project#235686, llvm/llvm-project#237688), so we can't access PhantomData directly from Vec. We'd need to do another type lookup by transplanting the generic param to the string "PhantomData<{generic_arg}>" and looking up that type. That's probably more reliable than what we're currently doing? Still not ideal though.