[RFC} threadsafe internal profiler

The profiler aufs assertions are caused by the profiler not being thread
safe but attempting to account operations inside each of the AIO
threads. Lack of thread safety is due to the stack the profiler
maintains of what states are currently being counted.

I don't believe we should be maintaining such a stack. Instead I think
we should leverage the existing system stack by having the PROF_start(X)
macro create a counter object in the local scope being counted. When the
local scope exists for any reason the system stack object will be
destructed and the destructor can accumulate the counters back into the
global data.

This saves us from mistakes balancing the counters as well as being
thread safe. It also reduces the overheads performing stack operations
to push/pop and validate the counters.

Opinions? alternatives?

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.10
   Beta testers wanted for 3.2.0.4