Add support for `FMV.S.X` and `FMV.X.S` mnemonics

[ThinkOpenly]

From the spec:

The FMV.W.X and FMV.X.W instructions were previously called FMV.S.X and FMV.X.S. The use of W is more consistent with their semantics as an instruction that moves 32 bits without interpreting them. This became clearer after defining NaN-boxing. To avoid disturbing existing code, both the W and S versions will be supported by tools.

Describe the solution you'd like
The current instructions should probably have pseudoinstruction mappings to the deprecated mnemonics to facilitate assembling old code.

Describe alternatives you've considered
Another option is to just not support the old mnemonics, but "will be supported" is a pretty strong statement.

[cavemansatyn-design]

Paul Clarke (@ThinkOpenly)
I investigated the current implementation and found that LLVM already supports fmv.s.x/fmv.x.s via MnemonicAlias, while UnifiedDB currently doesn't consume pseudoinstructions anywhere in code generation. Would you like this issue to add alias metadata for completeness, or are you envisioning changes that make the aliases visible in generated artifacts as well?

[cavemansatyn-design]

I investigated the existing implementation and repository conventions, and opened a PR implementing the smallest metadata-only change by adding pseudoinstructions mappings for the deprecated fmv.s.x and fmv.x.s mnemonics on the canonical instructions, following the existing alias pattern used elsewhere in the repository.

I'd appreciate any feedback on whether this matches the intended scope of the issue.