[fix](build) Strip sanitizer and platform-specific flags for OpenBLAS/FAISS

[heguanhui]

What problem does this PR solve?

Issue Number: close #64170

Related PR: #xxx

Problem Summary: On aarch64, building Doris BE with LSAN/ASAN/ASAN_UT/UBSAN sanitizer modes fails. This PR contains two commits to fix the issues.

---

Commit 1: Strip sanitizer and platform-specific flags for OpenBLAS/FAISS, cause run be ut failure on aarch64

1. LSAN/ASAN/ASAN_UT - CMake configuration failure: The OpenBLAS getarch build-time tool inherits sanitizer flags from the parent CMake context, causing LeakSanitizer to detect memory leaks in OpenBLAS's detect() function (strdup without free on aarch64). This makes getarch exit with non-zero code and CMake configuration fails.

   Fix: Strip sanitizer flags (-fsanitize=*, -fno-sanitize=*, -fsanitize-ignorelist=*) and -D*SANITIZER defines from CMAKE_C_FLAGS/CMAKE_CXX_FLAGS in cmake-protect/CMakeLists.txt before building OpenBLAS and FAISS.

2. UBSAN - -mcmodel=medium unsupported on aarch64: -mcmodel=medium is x86_64-specific and hardcoded in CXX_FLAGS_UBSAN, causing compilation failure in both OpenBLAS getarch and Doris BE targets.

   Fix: Move -mcmodel=medium in CXX_FLAGS_UBSAN to only apply on ARCH_AMD64. Also strip -mcmodel= in cmake-protect for OpenBLAS/FAISS.

3. TSAN - CMake configuration failure: The OpenBLAS getarch build-time tool inherits -fsanitize=thread flag, causing getarch to produce incorrect output with undefined macros.

   Fix: Covered by the same sanitizer flag stripping in cmake-protect. Verified TSAN works on aarch64 after the fix.

4. LSAN link error: __lsan_ignore_object was only enabled under ADDRESS_SANITIZER, but LEAK_SANITIZER also provides this symbol. Under LSAN mode, the empty stub was incorrectly used, causing link errors.

   Fix: Enable __lsan_ignore_object under both ADDRESS_SANITIZER and LEAK_SANITIZER in phdr_cache.cpp.

Files changed:

• be/src/storage/index/ann/cmake-protect/CMakeLists.txt — Strip sanitizer flags and -mcmodel=
• be/CMakeLists.txt — -mcmodel=medium only on ARCH_AMD64
• be/src/common/phdr_cache.cpp — __lsan_ignore_object for LEAK_SANITIZER

---

Commit 2: Fix UBSAN compilation failures on aarch64

After fixing -mcmodel=medium in commit 1, UBSAN build on aarch64 still fails due to -Wunused-macros errors (promoted to errors by -Werror):

1. -Wno-unused-macros suppression not working for flex/bison generated files: In be/src/exprs/CMakeLists.txt, -Wno-unused-macros was incorrectly gated behind the -Wno-unused-but-set-variable compiler flag check. If -Wno-unused-but-set-variable was not supported by the compiler, -Wno-unused-macros would also be skipped, causing flex/bison generated files (wkt_lex.l.cpp, wkt_yacc.y.cpp) to fail with unused macro errors.

   Fix: Separate the two flag checks into independent check_cxx_compiler_flag / if blocks.

2. Unused #define PMR macro in function_string_misc.cpp: The PMR macro was defined but never used anywhere in the file.

   Fix: Remove the unused #define PMR macros.

3. Unused ALIGN_CACHE_LINE and PURE macros in compiler_util.h: These macros are defined but never used anywhere in the codebase.

   Fix: Remove the unused macro definitions.

Files changed:

• be/src/exprs/CMakeLists.txt — Separate -Wno-unused-macros from -Wno-unused-but-set-variable conditional
• be/src/exprs/function/function_string_misc.cpp — Remove unused #define PMR
• be/src/common/compiler_util.h — Remove unused ALIGN_CACHE_LINE and PURE

---

Release note

None

Check List (For Author)

• Test

  • Regression test
  • Unit Test
  • Manual test (Verified LSAN/ASAN/ASAN_UT BE UT can build and run successfully on aarch64; UBSAN pending verification)
  • No need to test or manual test. Explain why:
    • This is a refactor/code format and no logic has been changed.
    • Previous test can cover this change.
    • No code files have been changed.
    • Other reason

• Behavior changed:

  • No.
  • Yes.

• Does this need documentation?

  • No.
  • Yes.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[zclllyybb]

what exactly error you have meet?

[heguanhui]

what exactly error you have meet?

#64170
you can see this issue to know about more error details.