Fast and dirty version of setting special value in TObject::new

Write special values into memory after TObject::new called in order to
have TObject's constructor determine if the object was made on the heap.
Removed use of TStorage::IsOnHeap

This is the only use of TStorage::IsOnHeap outside of TObject constructor.
It appears to be checking to see if the object might not be available anymore
and if so don't talk to it. This test is highly inadequate to answer that
question and since we want to get rid of TStorage::IsOnHeap for other reasons,
it was decided to remove its use here.
Cleaned up TStorage changes

Removed obsolete static member data and obsolete function bodies.
Added ::Obsolete calls where appropriate.
Encapsulate check on alloc in TStorage::FilledByObjectAlloc

Instead of having TObject's constructors know explicitly about how
TStorage::ObjectAlloc works, we no encapsulate that knowledge into
TStorage::FilledByObjectAlloc.
Additionally, switched from fBits to fUniqueID when checking for
assignment from 'new' in order to more easily create a valgrind
suppression entry.
Added suppression entries for determining if TObject on heap

To determine if TObject is on the heap we read the value of a member
data before it has been set by the constructor. If it was heap
allocated the TObject::operator new will have filled special values
into the memory area. However, for stack allocated it is
unset. This makes valgrind report an error. Given we intend this
behavior, we suppress the message.
Don't reset global in TClass::New

Helgrind was complaining about a global being written without a lock.
In this case, the global is not actually changed so we do a check
to see if the old value was the same as the value we set and if
so, we don't bother to change it.
Made TClass::fgCallingNew a thread_local file scope static

In order to avoid thread-safety issues, the static class member
TClass::fgCallingNew is no longer a class member and is instead
a file scoped static declared thread_local. It was necessary to
not have it is a class member since CINT could not parse the new
thread_local keyword.
Make variable used for GUID of TKeys atomic

Since TKeys can be made by different threads, it is necessary to
protect the global used to assign the GUID of TKeys,  keyAbsNumber
so that we are guaranteed to get a unique value for each request.
C++11 atomics give that guarantee.
Protect Cintex structure with mutex

The caching of TClasses by Cintext could be updated at anytime and
therefore needs to be protected when running multi-threaded.
Make zip globals thread local

The zip functions use globals to hold state while calling from
function to function. Such use is not thread safe. Given the globals
are only used during a function call chain, it is safe to change them
to thread local. Given this is compiled by a C compiler, we must use
the gcc specific __thread keyword.
Protect access to TROOT::GetListOfFiles()

When new files are opened or closed, gROOT->GetListOfFiles() is updated.
If the opening/closing happens on different threads then we need to
serialize all access to that list. This changes uses gROOTMutex to
serialize those accesses.
Protected threaded access to TClass::GetStreamerInfos()

The list of TStreamerInfos held by a TClass can change while processing
and therefore access to it must be protected when using multiple threads.
The gCINTMutex is used for this purpose since the TClass is considered
part of the CINT data model.
Thread safe caching of TStreamerInfo in TBranchSTL

We now protect all threaded access to TClass::GetStreamerInfos. In addition
this change properly handles updating the TStreamerInfo cache in a
thread safe manner.
Only set TStreamerInfo to unoptimized if it is optimized

When running with multiple threads, we need to avoid unnecessary changes
to TStreamerInfos. Therefore we check to see if the TStreamerInfo is optimized
before setting it as unoptimized and rebuild it.
Fix threading issues in TClass

The following threading issues were corrected
- TROOT::GetListOfClasses was protected via gCINTMutex
- Access to TStreamerInfo lists were protected via gCINTMutex
- Setting of the cache for current TStreamerInfo and for the list of
  conversion TStreamerInfos is protected via std::atomic<>
Made TPluginManager thread-safe for I/O

Several changes were needed to make this thread-safe for the I/O case
1) Protect the list of handlers with its own Mutex
2) Use a thread_local variable to hold the status of reading a directory
3) Use gCINTMutex to protect access to fBasesLoaded. Had to use gCINTMutex
 since we need threads trying to read the same dirs to wait for the first
 reader to finish so the lock has to be held over the whole call. In addition,
 gCINTMutex is sometimes taken before and sometimes during the call so using
 a different mutex would lead to a deadlock situation.
NOTE: fReadingDirs is not used anymore but is still in the code to allow
binary compatibility to easy testing. This should be removed in the future.
Mutex lock removed from TStorage::ObjectDealloc to avoid deadlocks

The order of locks between gGlobalMutex and gCINTMutex is undefined
and TStorage::ObjectDealloc calls were involved in order reversal
problems. As it turned out, there is no data structure that needs
protecting in TStorage::ObjectDealloc so we do not need the lock.
Use thread_local for statics in TUUID

TUUID used statics that were causing race conditions. The fix
was to change the statics to thread_local.
Fix thread-safety issues with TError

-There was a potential deadlock situation between gErrorMutex and
 gCINTMutex. The fix was to limit the scope of gErrorMutex locks
-Changed buffers from static to static thread_local. This allowed
 gErrorMutex to be more limited in scope.
Use gCINTMutex to protect access to G__getgvp

This fixed a problem found by helgrind.