Generic type name descriptions: massive problem

I've got into a blocking issue on CTS because of this.

In the [Table 165](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_description_of_the_built_in_types_available_for_sycl_host_and_device) there is an explosive mixture of types following [vector](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_aliases) and [marray](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_aliases_2) aliases. For example, `charn` gentype includes `char{n}, mchar{n}, marray<{N},char>` that (excluding misprint in marray defeinition) effectively covers `char` in `marray`, but `int8_t` in `char{n}` and `mchar{n}`. Then all the signatures that include e.g. `sgeninteger` are inherently contradictory as `sgeninteger` does not contain `int8_t` to match `char{n}`. Another aspect of the problem arises for e.g. `genlong` where it is possible to have `sycl::long2 = sycl::vec` plus `long = int32_t` (this is totally standard C++ behavior, for example in MSVC) and this generic type mixes 32 and 64-bit types.

The solution to the part of the problem was suggested in [this PR](https://github.com/KhronosGroup/SYCL-CTS/pull/462), but it is only palliative.

There are two ways out:
1. Simple: use full definitions like `vec` in the table instead of `char{n}` for `genchar`. This, however, leads to a potential leak in function definitions: then functions are not required to support e.g. `short2` as it is possible that on the C++ system `int16_t` is not in the list of fundamental types at all (for example 8-bit `char` and 32-bit `short` and `int` are fully compatible with the standard, and fixed types are not required to be aliases to any of fundamental types). This can be avoided by careful extension of the type tree of table 165 and a requirement that all fixed-size types should be supported for host and device [in Sec. 5.5](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#subsec:scalartypes).
2. Hard: change aliases system. AFAIK it follows from OpenCL and is aligned with `cl_` types, but in the current state that tries to align with C++ types it provides a lot of ways to shoot yourself in the foot.