[RISCV][CodeGen] Vector `Not(Sne)` sequences produced that can be simplified to `Seq`

Found when reviewing #221321.

`llc -mtriple=riscv64 -mcpu=sifive-p670 -verify-machineinstrs`

```llvm
define i1 @all_8(ptr %input) {
entry:
%tmp0 = load <8 x i8>, ptr %input, align 1
%tmp1 = trunc <8 x i8> %tmp0 to <8 x i1>
%tmp2 = call i1 @llvm.vector.reduce.and.v32i1(<8 x i1> %tmp1)
ret i1 %tmp2
}
```

results in

```asm
vsetivli zero, 8, e8, mf2, ta, ma
vle8.v v8, (a0)
vand.vi v8, v8, 1
vmsne.vi v8, v8, 0
vmnot.m v8, v8
vcpop.m a0, v8
seqz a0, a0
ret
```

Two separate issues here:
1. The `vmsne.vi - vmnot` sequence can be simplified to `vmseq`

```asm
vsetivli zero, 8, e8, mf2, ta, ma
vle8.v v8, (a0)
vand.vi v8, v8, 1
vmseq.vi v8, v8, 0
vcpop.m a0, v8
seqz a0, a0
ret
```

2. Could be instead lower to. Might be better handled in `vector-combine` (i.e. reverse the ordering of the `trunc` and `reduce.and`)

```asm
vsetivli zero, 8, e8, mf2, ta, ma
vle8.v v8, (a0)
vredand.vs v8, v8, v8
vmv.x.s a0, v8
ret
```

Start by reproducing the issue with the provided llc command and inspect the RISC-V vector-combine path mentioned in the report. Determine how the vmsne.vi/vmnot sequence is formed and whether the truncation and reduction ordering can be addressed there. Done means the generated sequence is simplified or lowered as intended while -verify-machineinstrs passes.

Written by the indexing model from the issue text.