When evaluating a transparent InitListExpr, eg. {{{{{{X}}}}}}} (when it's equivalent to a plain X), don't try to think of it as of a compound value of type X that contains an X - just think of it as of X itself.
I hope this should take care of the remaining problems that i identified in D59573, for which this patch is a follow-up.
On second thought, there shouldn't be any correctness problems because of multiple inheritance. If there's just one object in the initializer list, it's always at offset 0. So i don't think there are going to be any other changes in the actual behavior - just less crashes.
There's a chance that i missed other cases when a non-aggregate would be accidentally represented as a compound value, but i'm not immediately aware of such cases.
Add the original test from https://bugs.llvm.org/show_bug.cgi?id=41142 (the top-level recursive call would now evaluate into Unknown rather than compoundVal{Unknown} - which is still worse than the correct Undefined value, but it's at least not crashing). Btw, once we make sure it's Undefined, we should probably also add a path note indicating that the function returns a garbage value because there's no return statement in it on the current execution path.