Cleanup: Move thread_data_table_ to end of Isolate class.

In b49206de I changed thread_data_table_ and thread_data_table_mutex_ from
static members to regular class member variables. To do this, I only deleted
the `static` keyword and left the declarations where they were. This was a
little odd in that all of the dynamic class members are declared together in
one place, but now these two new members weren't next to the rest. Making it
a little bit weirder is the fact that these two new members actually ended up
being the first members of the class, since the exsiting dynamic members were
declared later.

This change merely moves these two members down to the end of the dynamic
member variable list, where they probably should have gone.

Bug: chromium:837477

Change-Id: If993935cc56c8026bb7331493ed657c42ba06ac7
Reviewed-on: https://chromium-review.googlesource.com/1036478Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52902}

src/isolate.h

@@ -1431,15 +1431,9 @@ class Isolate : private HiddenFactory {
     DISALLOW_COPY_AND_ASSIGN(EntryStackItem);
   };
 
-  // TODO(kenton@cloudflare.com): This mutex can be removed if
-  // thread_data_table_ is always accessed under the isolate lock. I do not
-  // know if this is the case, so I'm preserving it for now.
-  base::Mutex thread_data_table_mutex_;
-
   static base::Thread::LocalStorageKey per_isolate_thread_data_key_;
   static base::Thread::LocalStorageKey isolate_key_;
   static base::Thread::LocalStorageKey thread_id_key_;
-  ThreadDataTable thread_data_table_;
 
   // A global counter for all generated Isolates, might overflow.
   static base::Atomic32 isolate_counter_;
@@ -1683,6 +1677,12 @@ class Isolate : private HiddenFactory {
   const v8::Context::BackupIncumbentScope* top_backup_incumbent_scope_ =
       nullptr;
 
+  // TODO(kenton@cloudflare.com): This mutex can be removed if
+  // thread_data_table_ is always accessed under the isolate lock. I do not
+  // know if this is the case, so I'm preserving it for now.
+  base::Mutex thread_data_table_mutex_;
+  ThreadDataTable thread_data_table_;
+
   friend class ExecutionAccess;
   friend class HandleScopeImplementer;
   friend class heap::HeapTester;