Optimize RVV backend for Deconvolution and QuantizedAdd

[jxgxxx]

Description

This PR introduces pure RISC-V Vector (RVV) architectural optimizations for the CPU backend, specifically targeting the Deconvolution (weight transformation MNNDeconvTransformWeightC4) and QuantizedAdd operators.

Performance Benchmarks:

• Hardware: SG2044 64-Core RISC-V 64-bit
• OS: PolyOS Server 24.03 LTS

Function / Operator	Input Dimensions & Configuration	Baseline (C++)	RVV Optimized	Speedup	Correctness
MNNDeconvTransformWeightC4	M/OC=130, K/IC=64, kernel=3x3, area=9, outC4=33	605.405 ms	482.462 ms	1.25x	PASS
MNNDeconvTransformWeightC4	M/OC=128, K/IC=64, kernel=3x3, area=9, outC4=32	573.147 ms	462.189 ms	1.24x	PASS
CPUQuantizedAdd	elements=802816 (1x112x112x64), 1-thread, iter=200	4417.90 ms	194.379 ms	22.73x	PASS
CPUQuantizedAdd	elements=802816 (1x112x112x64), 4-threads, iter=500	49751.6 ms	22560.6 ms	2.21x	PASS

Module

CPU (specifically RVV backend)

Type

• Feature
• Bugfix
• Perf
• Refact
• Style
• Doc
• Test
• Chore

Checklist

• Commit message follows [Module:Type] Description format
• Code compiles without errors
• Tested on relevant platform(s)
• No unrelated format or style changes included

[wangzhaode]

Thanks for the RVV optimizations. The Deconvolution weight-layout logic looks good, but two issues need to be addressed before merging.

1. I tested the PR on a riscv64 board with GCC 15.2, MNN_USE_RVV=ON, and MNN_SUPPORT_DEPRECATED_OP=ON. The build fails in CPUQuantizedAdd.cpp at functions()->supportRVV because CoreFunctions is only forward-declared. Please include compute/CommonOptFunction.h or otherwise make the complete definition available.
2. Please make the RVV fixed-point rounding exactly match the existing scalar/NEON implementation. Using vsmul/vssra with RNU differs for some negative tie cases. An integer-formula comparison over 500,000 randomized cases found two uint8 outputs differing by 1 LSB. Please add coverage for negative intermediate values and rounding boundaries.

The Deconvolution C4/tail layout simulation passed. It would also be helpful to clarify the multi-thread benchmark methodology because the reported per-iteration numbers are not directly consistent with the single-thread results. Thanks!