Triton v3.6.x iluvatar backend and 5 TLE primitives support

[Salamanca001]

This PR brings the Iluvatar backend support onto Triton 3.6 in FlagTree and adds Iluvatar TLE lowering support.
Included commits:

• 7b4cac885 [BACKEND] update iluvatar backend support on triton3.6.
• 13abd15d8 [TLE][ILUVATAR] Add TLE support for alloc, local_ptr, copy, extract_tile and insert_tile.
  Main changes:
• Add third_party/iluvatar backend integration, including compiler/driver entry points, Iluvatar GPU dialect, lowering passes, target info, utility code, build wiring, and test runner.
• Add Iluvatar TLE dialect/lowering support for alloc, local_ptr, copy, extract_tile, and insert_tile.
• Add local pointer optimization passes, barrier insertion, TLE-to-LLVM lowering utilities, and registration into the Iluvatar build/dialect pipeline.
• Wire Iluvatar setup/build support into top-level CMake and Python setup helpers.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[zhzhcookie]

Example: https://github.com/flagos-ai/FlagTree/blob/triton_v3.6.x/python/setup_tools/utils/mthreads.py

[zhzhcookie]

elseif(FLAGTREE_BACKEND STREQUAL "iluvatar")

[sunnycase]

Thanks for the work here. Before this is finalized, could you please add a concise summary of the TLE primitive implementation plan?

It would be helpful to cover the main design points, such as the abstraction/lowering flow, compiler/runtime integration points, supported operator scope, dtype/shape/backend limitations, and the validation approach. Could you also include performance data for a few representative operators, ideally with baseline vs. TLE primitive numbers, test shapes, hardware/backend configuration, and measurement methodology?

For the expected level of detail and presentation style, PR #617 could be a useful reference: #617