Clarify support for long double

C++ has supported the `long double` type since C++ was first standardized. The SYCL specification does not currently acknowledge the existence of this type. It is therefore unclear what the intention is with regard to use of `long double` in SYCL programs.

Omitting support for `long double` has consequences beyond preventing programmers from directly using the type. C++11 introduced support for user-defined literals (UDLs) and the support for non-raw floating-point UDLs requires `long double` in the UDL function signature. See [\[lex.ext\]p4](http://eel.is/c++draft/lex.ext#4). For example:
```
struct my_fp_type { ... };
my_fp_type operator ""_my_fp_udl(long double);
```
The lack of `long double` support therefore prevents use of non-raw floating-point UDLs in SYCL device code (raw floating-point UDLs can still be defined and used).

If the intent is to omit support for `long double` in portable SYCL device code, then it would be helpful to amend the SYCL specification as follows:
- Amend [section 5.5 (Built-in scalar data types)](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#subsec:scalartypes) to explicitly note that `long double` is not specified for device code or that its size and alignment are not required to match the host. (It would be helpful to do likewise for other fundamental C++ types like `wchar_t`, `char8_t`, `char16_t`, and `char32_t`).
- Amend [section 2 (Introduction)](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#introduction) and [section 5.4 (Language restrictions for device functions)](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:language.restrictions.kernels) to list both `long double` and non-raw floating-point UDLs with the list of other C++ features that are restricted in device code.

Omission of `long double` is not the only option. There are a range of options along several dimensions. The following are a list of considerations.
- Whether the type is optionally supported (with a corresponding aspect like `fp64` for `double`).
- Whether it would be required for the size and alignment to match the host.
- Whether it would be required for the object representation to match the host.
- Whether object representation and values of the type must conform to an IEEE 754 format.
- Whether objects of the type can transit the host and device boundary and/or be accessed via USM.
- Whether objects of the type can be used in constant evaluation. Note that use in constant evaluation would impose no requirements on the device since evaluation would occur at compile time. Support could be limited to use in functions that are declared `consteval` or that are declared `constexpr` and only invoked in a constant evaluation context (contexts where `std::is_constant_evaluated()` evaluates to `true`).

This issue has been filed to:
1. Determine what the intent of the SYCL working group is, and
2. Update the specification to explicitly reflect that intent.