Use-after-dtor reports are hard to read

Originally reported on Google Code with ID 89

```
The "origin" portion of use-after-dtor reports on global variables looks something like
this:
#0 in __sanitizer_dtor_callback
#1 in MSanAtExitWrapper
#2 in __run_exit_handlers
...
# in __libc_start_main

There are 2 issues here:
1. There is no destructor frame. That's probably because __sanitizer_dtor_callback
is the last thing a destructor does, and it is tail-called. We should suppress tail-call
optimization in this case. This affects both global and heap-allocated objects.
2. For globals it should be possible to print the variable name (and the location of
the global definition). There is no support for this in MSan (because globals are almost
always initialized); there is code in TSan that does this and support in llvm-symbolizer.
3. I wonder how hard it would be to do the same for local (stack) variables.

```

Reported by `eugenis@google.com` on 2015-07-21 23:31:21

Start by comparing the existing ThreadSanitizer global-reporting code with llvm-symbolizer support, then trace __sanitizer_dtor_callback and MSanAtExitWrapper. Determine how destructor frames, global names, and definition locations are represented; completion would address the reported global and heap cases and clarify whether local-variable reporting is feasible.

Written by the indexing model from the issue text.