When a temporary is constructed into a CXXBindTemporaryExpr (i.e. when it needs a destructor), we can (since D43056/D43062) pick up the construction context and be sure that the temporary is initialized correctly.
Now, store the initialized temporary region in the program state with CXXBindTemporaryExpr as its key, and when the time comes to call the destructor, lookup the CXXBindTemporaryExpr in the CFGTemporaryDtor element, then lookup the region in the program state.
For this purpose, the existing program state trait is used - the one that was added by @klimek for making sure that the control flow for ternary operators with temporaries is correct. Now the region is also stuffed into it. Technically, it should be possible to reconstruct the region by having just the temporary-expression and the location context. However, this would require duplicating a bit of logic from the CFG.
When the this-region is available this way, give ourselves the privilege to attempt inlining it. Of course, normal limitations of what we will or will not inline will still apply.
Additionally, prevent the temporary from being garbage-collected from the program state until the destructor call. I don't think SymRegion::isLiveRegion() should be taught to query ExprEngine regarding live temporaries - we should be just fine treating it as a regular program state trait value liveness process. Also in this case LiveVariables analysis isn't going to help much: temporaries definitely outlive their CXXBindTemporaryExprs sometimes. So i have an impression that this is the right way to solve the liveness issue this time.