Reductions and scans: types allowed

In the spec [4.17.4.5](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_reduce) and [4.17.4.6](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_exclusive_scan_and_inclusive_scan) all the functions are defined for "fundamental types" that are defined in [5.5, Table 183](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#subsec:scalartypes) and only mentioned in the spec [once outside of these sections](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:reduction). They do not include `sycl::half`, however, that is an oversight for the functions supposed to support reduction/scan also of half precision numbers. Two solutions are

1. Add `sycl::half` to the table of SYCL supported fundamental types like `double` (that is also optional on device side). Maybe it is not optimal, taking into account what traits should be guaranteed for C++ fundamental type. Then should SYCL fundamental type imply all the properties of C++ fundamental type? The SYCL supported fundamental types are also called "scalar types" and additional "scalar types" [are listed in Table 142](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_scalar_data_types). Maybe "scalar types" can be used instead of "fundamental types"? `sycl::byte` is deprecated, however.
2. Add `sycl::half` to every mention of "fundamental types" in reduce/scan functions (or introduce something like "reducible types" = "fundamental types" + `sycl::half`, and use this term).

Start with SYCL specification sections 4.17.4.5 and 4.17.4.6, then compare the definitions in section 5.5 Table 183 and Table 142. Determine which type terminology should govern reductions and scans, including sycl::half, and update the affected specification wording once the scope is decided.

Written by the indexing model from the issue text.