[rttr] Disable -Werror in order to support android

[FrankXie05]

Fix #37123

Note:
In C++, if two values of different types are operated on or compared, the compiler attempts an implicit type conversion to convert one value to the type of the other. This implicit type conversion may result in loss of precision, overflow, or incorrect results。
Now change to the result of explicit conversion for android.

Upstream PR: rttrorg/rttr#371

• Changes comply with the maintainer guide.
• SHA512s are updated for each updated download.
• The "supports" clause reflects platforms that may be fixed by this new version.
• Any fixed CI baseline entries are removed from that file.
• Any patches that are no longer applied are deleted from the port's directory.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is added to each modified port's versions file.

[dg0yt]

rttrorg/rttr#371 (comment)

[FrankXie05]

Regarding the precision of the values, they are well below the precision range of float(-2^128 ~ +2^128).

(aka 'int') to 'float' changes value from -2147483647 to -2147483648
(aka 'long') to 'float' changes value from 9223372036854775807 to 9223372036854775808

[dg0yt]

Regarding the precision of the values, they are well below the precision range of float(-2^128 ~ +2^128).

(aka 'int') to 'float' changes value from -2147483647 to -2147483648
(aka 'long') to 'float' changes value from 9223372036854775807 to 9223372036854775808

Precision is not min/max value. Precision is number of signifcant bits. It is relevant for floating point type which use part of the bits for the exponent.
https://en.wikipedia.org/wiki/Floating-point_arithmetic
So there can be integer numbers which are within the min/max range of a given floating point type but cannot be represented exactly.

In addition, the ranges of int, float, and log are not defined exactly. Only the minimum range can be assumed for each type.

Now the patched function is only to indicate if a value is too small or too large to fit into the floating point type. Maybe the patch is acceptable because precision is not an issue here. But correct transition between fp and integer can be tricky, and so it should be reviewed carefully.

[Cheney-W]

Add reviewed tag to request further review from Billy.

[BillyONeal]

I'm not convinced that this patch is correct in the face of all types F and T. In particular, it's not necessarily true that numeric_limits<T>::max is representable in F. The correctness of this depends on the intended interface of the function in question and how it is used.

I do not think it is appropriate to apply a change like this without upstream having made the change first. It is not clearly only build system related or similarly related to our core competencies, so I don't think even a waiting period is appropriate.

If the actual build failure is due to some sort of warning that fires on Android, turning off the warning would be OK.

[BillyONeal]

Awesome, thanks!