Fix non-clang build failure around STACK_ALLOCATED macro

STACK_ALLOCATED macro leaves `private:` section on clang build after
https://crrev.com/c/1160424, and doesn't change the access specifier
on non-clang build, that seems to confuse non-clang build.

This CL unifies the difference to fix the non-clang build.

Change-Id: I0fdd1236670a5dd64892c19fa642dd4d681e4008
Reviewed-on: https://chromium-review.googlesource.com/1164156Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
Cr-Commit-Position: refs/heads/master@{#581144}

third_party/blink/renderer/platform/wtf/allocator.h

@@ -71,20 +71,21 @@ class __thisIsHereToForceASemicolonAfterThisMacro;
   friend class ::WTF::internal::__thisIsHereToForceASemicolonAfterThisMacro
 
 #if defined(__clang__)
+#define ANNOTATE_STACK_ALLOCATED \
+  __attribute__((annotate("blink_stack_allocated")))
+#else
+#define ANNOTATE_STACK_ALLOCATED
+#endif
+
 #define STACK_ALLOCATED()                                       \
  public:                                                        \
   using IsStackAllocatedTypeMarker[[maybe_unused]] = int;       \
                                                                 \
  private:                                                       \
-  __attribute__((annotate("blink_stack_allocated"))) void* operator new( \
-      size_t) = delete;                                                  \
+  ANNOTATE_STACK_ALLOCATED void* operator new(size_t) = delete; \
   void* operator new(size_t, NotNullTag, void*) = delete;       \
   void* operator new(size_t, void*) = delete
 
-#else
-#define STACK_ALLOCATED() DISALLOW_NEW()
-#endif
-
 // Provides customizable overrides of fastMalloc/fastFree and operator
 // new/delete
 //