Vector API FP reduction tests should not test for exact equality

Certain floating point reduction operations in the Vector API are allowed to introduce rounding errors, see https://docs.oracle.com/en/java/javase/20/docs/api/jdk.incubator.vector/jdk/incubator/vector/VectorOperators.html#fp_assoc : "Certain associative operations that apply to floating point vectors are not truly associative on the floating point lane values. Specifically, ADD and MUL used with cross-lane reduction operations, such as FloatVector.reduceLanes(Associative). The result of such an operation is a function both of the input values (vector and mask) as well as the order of the scalar operations applied to combine lane values. In such cases the order is intentionally not defined. This allows the JVM to generate optimal machine code for the underlying platform at runtime. If the platform supports a vector instruction to add or multiply all values in the vector, or if there is some other efficient machine code sequence, then the JVM has the option of generating this machine code. Otherwise, the default implementation is applied, which adds vector elements sequentially from beginning to end. For this reason, the result of such an operation may vary for the same input values."

The jtreg tests for these operations do not take this into account, and they test for exact equality of the results with the Java reference implementation. The current version of C2 generates code that matches the results of the Java reference implementation. Future versions of C2, or alternative compilers, can generate more efficient machine code sequences that do not match this reference value exactly.

The tests in test/jdk/jdk/incubator/vector should be changed to allow the result of floating point reductions with ADD or MUL to differ from the reference value by some small relative error, such as 0.1%.