Revert 107939 - Pile of nits for tracked object enablement

Revert 107939 - Pile of nits for tracked object enablement

[Re-land of Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=107921
with supressions for induced (and planned) leaks) 
PLUS
Removed one line of defensive coding where I set(NULL)
the TLS slote at thread teardown. We're seeing
strange failures on the base unittests, and they
may be related to this.
]

Be extra carful about handling races in access to status_.
This will avoid generating a delta between a null time
and a real time, when status is changing in/around
the run of a task. This won't help with the benign
race for checking status_, but it may help with unit
test tsan complaints.

Leak data aggressively, rather than cleaning up, to
prevent any chance of a data access race between
tracked object testing (which need a near-virgin
global state, and hence must start by cleaning it up), and
other tests, which may have lingering threaded actions, 
that still access some previously created task tracking
data.

Provide more options for flags to enable/disable
tracking. These options might become useful
if we changed the default to not do tracking.

Allow for HTML generation even if the tracking has
changed to being disabled. This is especially useful
for looking at the tracked instances that were
monitored after turning tracking on by default, but
before the command line deactiated tracking.

tbr=rtenneti
bug=102327
Review URL: http://codereview.chromium.org/8425010

TBR=jar@chromium.org
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=107960