Workaround for ASAN stack safety analysis problem with FixedArray container annotations.

The problem is that the underlying storage adds redzone after the actual data so from compiler's perspective it looks like a valid memory. In the outlined version the memory is returned in call.i.i with unknown size so the access check can't be removed. The workaround is to always outline the call to InitializeData for ASAN builds.

Outlined version:
  %call.i.i = call noundef i32* @absl::FixedArray<int, 4ul, std::__u::allocator<int> >::Storage::InitializeData()(...), !dbg !28
  store i32* %call.i.i, i32** %data_.i.i, align 8, !dbg !27
  %arrayidx = getelementptr inbounds i32, i32* %call.i.i, i64 5, !dbg !29
  %24 = bitcast i32* %arrayidx to i8*, !dbg !29
  call void @llvm.asan.check.memaccess(i8* %24, i32 36), !dbg !29
  store i32 0, i32* %arrayidx, align 4, !dbg !29

Inlined version:
 %arrayidx = getelementptr inbounds %"class.absl::FixedArray", %"class.absl::FixedArray"* %7, i64 0, i32 0, i32 0, i32 1, i64 20, !dbg !40
  %27 = bitcast i8* %arrayidx to i32*, !dbg !40
  >>>>>>>>>>>>>>> call to @llvm.asan.check.memaccess removed <<<<<<<<<<<<<<
  store i32 0, i32* %27, align 4, !dbg !40

Workaround for ASAN stack safety analysis problem with FixedArray container annotations.

PiperOrigin-RevId: 471583635
Change-Id: I0d74eed5782a1cbd340ca4aca1bce71b63b06d43

absl/container/fixed_array.h

@@ -471,6 +471,9 @@ class FixedArray {
       return n <= inline_elements;
     }
 
+#ifdef ABSL_HAVE_ADDRESS_SANITIZER
+    ABSL_ATTRIBUTE_NOINLINE
+#endif  // ABSL_HAVE_ADDRESS_SANITIZER
     StorageElement* InitializeData() {
       if (UsingInlinedStorage(size())) {
         InlinedStorage::AnnotateConstruct(size());