Thread activity tracker: do not use anonymous namespace union.

Move anonymous namespace union ThreadRef to non anonymous namespace
to avoid this warning in GCC:
/../../../chromium-68.0.3432.3/base/debug/activity_tracker.cc:605:31:
warning: 'base::debug::ThreadActivityTracker::Header' has a field
'base::debug::ThreadActivityTracker::Header::thread_ref' whose type
uses the anonymous namespace [-Wsubobject-linkage]
 struct ThreadActivityTracker::Header {

It is discouraged to use in a public type a type declared in an
anonymous namespace. It should not be a problem in our case as it
is only used internally in activity_tracker.cc, but GCC will still
complain in jumbo build as the .cc is used as an include.

Change-Id: I121af0053b5ee51661be99ae4470512909416859
Reviewed-on: https://chromium-review.googlesource.com/1066001
Commit-Queue: José Dapena Paz <jose.dapena@lge.com>
Reviewed-by: Brian White <bcwhite@chromium.org>
Cr-Commit-Position: refs/heads/master@{#561406}

base/debug/activity_tracker.cc

@@ -52,21 +52,6 @@ const char kProcessPhaseDataKey[] = "process-phase";
 // in the same memory space.
 AtomicSequenceNumber g_next_id;
 
-union ThreadRef {
-  int64_t as_id;
-#if defined(OS_WIN)
-  // On Windows, the handle itself is often a pseudo-handle with a common
-  // value meaning "this thread" and so the thread-id is used. The former
-  // can be converted to a thread-id with a system call.
-  PlatformThreadId as_tid;
-#elif defined(OS_POSIX) || defined(OS_FUCHSIA)
-  // On Posix and Fuchsia, the handle is always a unique identifier so no
-  // conversion needs to be done. However, its value is officially opaque so
-  // there is no one correct way to convert it to a numerical identifier.
-  PlatformThreadHandle::Handle as_handle;
-#endif
-};
-
 // Gets the next non-zero identifier. It is only unique within a process.
 uint32_t GetNextDataId() {
   uint32_t id;
@@ -121,6 +106,21 @@ Time WallTimeFromTickTime(int64_t ticks_start, int64_t ticks, Time time_start) {
 
 }  // namespace
 
+union ThreadRef {
+  int64_t as_id;
+#if defined(OS_WIN)
+  // On Windows, the handle itself is often a pseudo-handle with a common
+  // value meaning "this thread" and so the thread-id is used. The former
+  // can be converted to a thread-id with a system call.
+  PlatformThreadId as_tid;
+#elif defined(OS_POSIX) || defined(OS_FUCHSIA)
+  // On Posix and Fuchsia, the handle is always a unique identifier so no
+  // conversion needs to be done. However, its value is officially opaque so
+  // there is no one correct way to convert it to a numerical identifier.
+  PlatformThreadHandle::Handle as_handle;
+#endif
+};
+
 OwningProcess::OwningProcess() = default;
 OwningProcess::~OwningProcess() = default;