Integer conversion in SYCL floating-point math functions

The [C++ draft for cmath](https://eel.is/c++draft/c.math#cmath.syn-3) states that:

> For each function with at least one parameter of type floating-point-type other than abs, the implementation also provides additional overloads sufficient to ensure that, if every argument corresponding to a floating-point-type parameter has arithmetic type, then every such argument is effectively cast to the floating-point type with the greatest floating-point conversion rank and greatest floating-point conversion subrank among the types of all such arguments, where arguments of integer type are considered to have the same floating-point conversion rank as double[.](https://eel.is/c++draft/c.math#cmath.syn-3.sentence-1) If no such floating-point type with the greatest rank and subrank exists, then overload resolution does not result in a usable candidate ([[over.match.general]](https://eel.is/c++draft/over.match.general)) from the overloads provided by the implementation[.](https://eel.is/c++draft/c.math#cmath.syn-3.sentence-2)

However, SYCL 2020 makes no such guarantees about overloads for its math functions, effectively meaning calling floating-point math functions (e.g. `sycl::cos`) with an integer may cause ambiguity errors as either the `float` or `double` overloads are valid for it, while the corresponding cmath math functions (e.g. `std::cos`) would follow the aforementioned rules and pick the appropriate overload accordingly.

Should SYCL adopt similar rules to make porting from cmath to the equivalent SYCL math functions simpler?

Start with the linked C++ draft cmath rules and compare them with the SYCL 2020 math-function requirements described in the issue. Determine whether integer arguments should receive equivalent floating-point overload treatment; done would be a resolved specification decision, with any resulting SYCL documentation changes identified.

Written by the indexing model from the issue text.