[mlir][NVVM] LLVM IR import drops @llvm.nvvm.barrier.cta.sync.* intrinsics

When importing LLVM IR into MLIR via `mlir-translate -import-llvm`, calls to the `@llvm.nvvm.barrier.cta.sync.{aligned.,}{all,count}` intrinsic
family are dropped from the resulting MLIR module instead of being mapped to `nvvm.barrier`.

The minimal reproducible example is:

```llvm
// mlir-translate -import-llvm -emit-expensive-warnings %s
target datalayout = "e-i64:64-i128:128-v16:16-v32:32-n16:32:64"
target triple = "nvptx64-nvidia-cuda"

declare void @llvm.nvvm.barrier.cta.sync.aligned.all(i32)

define void @kernel() {
call void @llvm.nvvm.barrier.cta.sync.aligned.all(i32 0)
ret void
}
```

The output message is:
```
barrier.ll:0:0: warning: unhandled data layout token: v16:16
barrier.ll:0:0: warning: unhandled data layout token: v32:32
:0: warning: dropped instruction: call void @llvm.nvvm.barrier.cta.sync.aligned.all(i32 0)
module attributes {dlti.dl_spec = #dlti.dl_spec : vector<2xi64>, i128 = dense<128> : vector<2xi64>, !llvm.ptr = dense<64> : vector<4xi64>, i1 = dense<8> : vector<2xi64>, i8 = dense<8> : vector<2xi64>, i16 = dense<16> : vector<2xi64>, i32 = dense<32> : vector<2xi64>, f16 = dense<16> : vector<2xi64>, f64 = dense<64> : vector<2xi64>, f128 = dense<128> : vector<2xi64>, "dlti.endianness" = "little", "dlti.legal_int_widths" = array>, llvm.module_asm = [], llvm.target_triple = "nvptx64-nvidia-cuda"} {
llvm.func @llvm.nvvm.barrier.cta.sync.aligned.all(i32) attributes {convergent, no_unwind, nocallback}
llvm.func @kernel() {
%0 = llvm.mlir.constant(0 : i32) : i32
llvm.call_intrinsic "llvm.nvvm.barrier.cta.sync.aligned.all"(%0) : (i32) -> ()
llvm.return
}
}
```
Background
The NVVM dialect's LLVMImportDialectInterface does not claim these intrinsic IDs in getSupportedIntrinsics() and there is no custom
import path for them in LLVMIRToNVVMTranslation.cpp, so the generic LLVM IR importer drops them.

This issue tracks the import side specifically. Two related changes are:
Adding an explicit aligned attribute to nvvm.barrier so the aligned and non-aligned intrinsic spellings can both be modeled losslessly. Tracked separately and being addressed in PR #192203.
Importing the reduction-variant intrinsics (@llvm.nvvm.barrier.cta.red.*) is blocked on a separate issue with BarrierOp's result type for and/or reductions (currently i32 with a zext, should match the intrinsic's i1 return). Out of scope for this issue.