Keep track names

Summary:
`threadNames_` is a map from thread id to thread name.

This is the only place where this map is populated:
https://www.internalfb.com/code/fbsource/[9c9ffce4179fbc0c3f05c370646ec159cc4fb6a1]/xplat/hermes/lib/VM/Profiler/SamplingProfiler.cpp?lines=129-132

Since this only happens in a constructor, I don't really understand why it has to be a map. A single thread will be recorded, basically the one on which the instance of SamplingProfiler is created.

We have a `clean()` function, which basically resets the state of `SamplingProfiler` and wipes out everything we could've just emitted via one of the JS Samplings APIs.

This API also cleans thread names map, but this single thread inside this map might still be alive and this SamplingProfiler instance is not destroyed, so this thread entry will never be registered again.

This might be not the best fix for this issue, and I am open to changing the approach:
- Do we really need to keep a map of thread names here?
- Can some methods on `SamplingProfiler` be executed on a thread different from the one where `SamplingProfiler` was created?

My current understanding is that `Sampler` is a global instance, which keeps references to potentially multiple local `SamplingProfiler` instances, which may be on different threads, but `SamplingProfiler` <-> `Thread` relationship is 1 <-> 1.

Reviewed By: mattbfb

Differential Revision: D67453370

fbshipit-source-id: 55dc308c46b0dfa9116904fa2d32c5341940ecd6

lib/VM/Profiler/SamplingProfiler.cpp

@@ -246,8 +246,6 @@ void SamplingProfiler::clear() {
   // Release all strong roots.
   domains_.clear();
   nativeFunctions_.clear();
-  // TODO: keep thread names that are still in use.
-  threadNames_.clear();
 }
 
 void SamplingProfiler::suspend(