heapprofd: mitigate potential data race during UnwindingWorker destruction

UnwindingWorker instances are intended to have an associated worker
thread, which should be the only thread mutating the
not-otherwise-synchronized (i.e.  task_runner) state of the
UnwindingWorker. However, the way I originally implemented it using
base::ThreadTaskRunner turns out to be incorrect, as we're still
constructing and, more importantly, destructing, the UnwindWorker
instances on the *main* thread.

The potential race is either during final shutdown, or the reconnect
sequence (which self-destructs and recreates the owning producer
instance). The destructor ends up running on the main thread while the
task thread is potentially actively modifying its state.

I believe that moving the base::ThreadTaskRunner to be the last memeber
mitigates the issue. Though we should still fix it properly.

Note that the original comment about keeping the ThreadTaskRunner first
is bogus in retrospect.

Change-Id: I22a6ad8e986279d6c5db4532f708691ea98e7de5