We were previously registering the Android UI thread with the profiler using
the `PROFILER_REGISTER_THREAD` macro.
This macro uses the address of a local variable as an estimate for the top of
the thread's call stack. The profiler's sampling thread does not walk the stack
any further past this value.
This works fine most of the time, as it's usually one of the first things that
we do when running a new thread.
On the other hand, the Android UI thread already has a bunch of stuff on the
stack (including VM frames) by the time we go to set this, plus we have two or
three of our own calls already on the stack as well. Using the current stack
frame as an estimate for the top of the stack results in the profiler omitting
numerous frames from the Android UI thread because it mistakenly believes that
it needs to stop walking the stack sooner than it actually needs to!
Instead of using the macro, this patch uses pthreads to resolve the real stack
top and supplies that pointer to the profiler instead.
Differential Revision: https://phabricator.services.mozilla.com/D116284
