[Fix][Relax] Skip FuseOps groups that have no call to fuse

[wwoosshh]

Fixes #20194.

FuseOps treats TupleGetItem as injective, so two chained TupleGetItem bindings form a group with two nodes, as a and b do here:

inner = (x, x)
outer = (inner, x)
a = outer[0]
b = a[0]

Only single-node groups were left unfused, so FuseOps created a Primitive function for this group. FunctionCreator then moves the first TupleGetItem to the caller to pass the used tuple field directly, which leaves a function with no call_tir and the default name fused. FuseTIR names the fused PrimFunc after the PrimFuncs it calls, so it rejects that function with Check failed: (func_info_.global_name != "fused"). The nested tuple case in the issue hits this with the LLVM default pipeline.

This PR keeps the bindings of a group without any call as they are, the same way as a single-node group, since there is nothing to fuse. Groups created by FuseOpsByPattern carry attributes and are not affected.

Testing: added test_tuple_get_item_chain_without_call to tests/python/relax/test_transform_fuse_ops.py. It fails on main, where FuseOps creates the fused function, and passes with this change. test_transform_fuse_ops.py (33 tests), test_transform_fuse_tir.py (35) and test_transform_fuse_ops_by_pattern.py (29) pass, and the reproducer from the issue now builds and runs with the LLVM default pipeline for both tuple depths.

Generated-by: Claude Code (Claude Opus 5.5)

[wwoosshh]

cc @tlopex @tqchen

This fixes #20194: FuseOps no longer creates a fused function for a group that has no call, such as a chain of TupleGetItem, which FuseTIR could not lower. Could you take a look when you have time?