[unsound-mint]

Fixes #833.

@fastmath replaces max, min, + and * with max_fast, min_fast, add_fast and mul_fast. Reductions with these were slower than with the plain operators, for two reasons:

• neutral_element had no methods for them, so AcceleratedKernels seeded every partial result with an empty lane instead. The first commit adds the four methods to GPUArraysCore. That makes this a GPUArraysCore 0.2.2 release, with the pin in the root Project.toml updated as in Move neutral_element to GPUArraysCore #789.
• Since Reduce with operators not known to commute in element order #822, only operators known to commute use AcceleratedKernels' unordered kernels. The second commit adds the @fastmath operators to _commutative, on the same types as the operators they replace. Strictly they commute only up to NaNs and the sign of zero, which @fastmath may ignore anyway.

Times in µs on an RTX 5080, @fastmath reduce(op, x; dims, init) against the plain reduce(op, ...), L2 cache flushed, minimum of 20 runs:

case	max	max_fast on main	max_fast with this PR
Float32 1024×1024×96, dims=1	471	940	471
BFloat16 1024×1024×96, dims=1	442	926	442
Float32 768×8192, dims=2	37	72	37

add_fast and scalar (dims=:) reductions behaved the same way. The main column is from before #822, when BFloat16 max took 242 µs. BFloat16 isn't an IEEEFloat, so #822 sends its plain reductions down the ordered path too. That's a separate issue.

One visible difference: a @fastmath sum of -0.0 values now returns 0.0, because add_fast is seeded with +0.0. @fastmath permits this.

Tests:

• the neutral elements of the four operators (these fail on main);
• _commutative for the @fastmath operators;
• one @fastmath reduction per operator and real element type, compared against the CPU.