Type-selection of xform is wrong when has complex Pars, and converted [o] Pars in flowing xforms don't work

[mohawk2]

This is discussed in https://pdl.perl.org/advent/blog/2024/12/20/pdl-internals/

Type selection

• The type-selection broke PDL::FFTW3's real -> native complex FFT. The latest has a workaround that avoids using type_coerce. As noted in the article above, the type-detection should correctly detect including for complex Pars, though that should be fixed last after the other issue.
• The type-selection should prioritise outputs over inputs, since the final results after any potential type-converting will be dictated by them anyway (putting aside questions of operating at higher precision to get more accurate results).
• Type-selection could be simplified in the one-type case by detecting there's only one type, and just picking that.
• Restore the 2.095 behaviour of: when no typed (i.e. non-null) outputs, any non-available-typed input will select last-given-type, not an available-typed input type (see github actions failing under PDL-2.096 moocow-the-bovine/PDL-CCS#18 (comment) for test case)

Type conversion

• When an output must be converted, because its type isn't an available option for that xform, then pdl_converttypei_new would be called with the ndarray params the non-usual way round, with the input null's datatype being set to the xform's, and the output being the original supplied input.
• In the case where it already has a trans_parent, this would instead cause an error.
• Forbid null being passed to [io] Pars.

xform inputs from Perl values being made into ndarrays too soon, and thus having a type assigned that requires converting

• The XS code part of xforms could be enhanced to analyse the supplied Perl parameters, and use the xform spec to determine the required type for each. It could then make ndarrays out of the Perl values with the required type, avoiding the need for conversion.
• A further benefit from that would be in generating versions of readdata (backward dataflow wouldn't make sense) that only processed Perl SVs, which would avoid overhead in the Perl-value-only scenario (and allow removing the PMCode for log10).

Other thoughts

• For generated redodims/readdata/writebackdata functions, they should merge the indx and either long or longlong case, since they are functionally identical and it's a bit less code to generate.
• non-[o] OtherPars should be copied into stack vars at the start of r/w functions, and be forced as rvalues.