[CIR][CIRGen][TBAA] Initial TBAA support

[PikachuHyA]

This is the first patch to support TBAA, following the discussion at https://github.com/llvm/clangir/pull/1076#discussion_r1835031415

• add skeleton for CIRGen, utilizing decorateOperationWithTBAA
• add empty implementation in CIRGenTBAA
• introduce CIR_TBAAAttr with empty body
• attach CIR_TBAAAttr to LoadOp and StoreOp
• no handling of vtable pointer
• no LLVM lowering

[PikachuHyA]

Summary of Changes

• Added alias printing for CIR_TBAAAttr.
• Moved TBAA printing to the end of the output.
• Unified variable names to use camelCase.
• Revised comments for clarity.
• Removed unnecessary debug output.

Explanations

• Why is the type of TBAA mlir::ArrayAttr?
  The introduction of the tbaa attribute as OptionalAttr<SymbolRefArrayAttr> is in the commit https://github.com/llvm/llvm-project/commit/edfefd7fc50b995c4dfd81d5f9db53c1a9e11580 . The follow-up changes made in https://github.com/llvm/llvm-project/commit/1dda134f85d4fab7ace7b9ec9b57a0319c14de8f further address this design choice, which changes tbaa attribute as OptionalAttr<LLVM_TBAATagArrayAttr>.

  The rationale behind this decision stems from the following comment:

  // LLVM IR currently does not support attaching more than one TBAA access tag
  // to a memory accessing instruction. While supporting this in the future may
  // be beneficial, for now we simply ignore the metadata if the MLIR operation
  // has multiple access tags.

  For additional context, please refer to ModuleTranslation.cpp#L1101-L1109.

  In this patch, we use mlir::ArrayAttr to simplify the TBAA attribute, allowing for a quicker landing of the patch. We will refine the TBAA attribute design in the next patch.

[bcardosolopes]

• In this patch, we use mlir::ArrayAttr to simplify the TBAA attribute, allowing for a quicker landing of the patch. We will refine the TBAA attribute design in the next patch.

I dislike optional because there are two levels on null checking here (the optional could be empty and the array could also be empty), which is quite confusing. Better yet that LLVM doesn't really support multiple entries. I suggested to you in previous comments to create a new attr if necessary to wrap the array exactly for this reason: the array becomes an implementation detail and it doesn't really matter if we remove the array later, since it's internal state of the attribute.

Anyways, I'm fine if this comes as incremental work though. Thanks