Is restriction on calling virtual member functions from device functions too strict?

[5.4. Language restrictions for device functions](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:language.restrictions.kernels) lists the following restriction (emphasis mine):

> The odr-use of polymorphic classes and classes with virtual inheritance is allowed. **However, no virtual member functions are allowed to be called in a [device function](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#device-function).**

As I read this, no call to a virtual member function is allowed, even if the call is in fact direct, i.e. it does not involve virtual call mechanism. There are a few situations where the latter could occur:

From [class.virtual.16](https://eel.is/c++draft/class.virtual#16):

> Explicit qualification with the scope operator ([[expr.prim.id.qual]](https://eel.is/c++draft/expr.prim.id.qual)) suppresses the virtual call mechanism[.](https://eel.is/c++draft/class.virtual#16.sentence-1)
> [Example [10](https://eel.is/c++draft/class.virtual#example-10): 
> ```c++
> class B { public: virtual void f(); };
> class D : public B { public: void f(); };
> void D::f() { /* ... */ B::f(); }
> ```
> Here, the function call in `D​::​f` really does call `B​::​f` and not `D​::​f`[.](https://eel.is/c++draft/class.virtual#16.sentence-2) — end example]

Also, [expr.call.2](https://eel.is/c++draft/expr.call#2) (emphasis mine) suggests that there are cases when a call to a virtual member function is not considered to be a virtual call:

> If the selected function is non-virtual, **or if the [id-expression](https://eel.is/c++draft/expr.prim.id.general#nt:id-expression) in the class member access expression is a [qualified-id](https://eel.is/c++draft/expr.prim.id.qual#nt:qualified-id), that function is called[.](https://eel.is/c++draft/expr.call#2.sentence-1)** Otherwise, its [final overrider](https://eel.is/c++draft/class.virtual#def:final_overrider) in the dynamic type of the object expression is called; such a call is referred to as a [virtual function call](https://eel.is/c++draft/expr.call#def:function,virtual_function_call)[.](https://eel.is/c++draft/expr.call#2.sentence-2)
[Note [2](https://eel.is/c++draft/expr.call#note-2): The dynamic type is the type of the object referred to by the current value of the object expression[.](https://eel.is/c++draft/expr.call#2.sentence-3) [[class.cdtor]](https://eel.is/c++draft/class.cdtor) describes the behavior of virtual function calls when the object expression refers to an object under construction or destruction[.](https://eel.is/c++draft/expr.call#2.sentence-4) — end note]

I.e. even if a selected function is virtual, but the class member access expression is in a certain form, the call is not considered to be a virtual call, but instead it is just a direct call to the said function. I'm properly lost in all those `id-expression`, `qualified-id` and other terms from the C++ draft spec, but my understanding is that there is no virtual call mechanism involved in an example below:

```c++
struct Base {
virtual void foo();
};

void bar() {
Base b;
b.foo();
}
```

If my reading of both specs is correct, then we should update the restriction in the SYCL spec to say something like this (emphasis to highlight the diff):

> The odr-use of polymorphic classes and classes with virtual inheritance is allowed. However, **no virtual functions calls are allowed to be performed** in a [device function](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#device-function).

I.e. we only disallow cases where virtual call mechanism is involved, but we allow direct (i.e. non-virtual) calls to functions that are defined as virtual.

Start by reviewing SYCL specification section 5.4 and the cited C++ standard clauses on virtual calls, qualified-ids, and explicit qualification. Confirm the intended distinction with the specification maintainers; done means the restriction wording accurately reflects the agreed treatment of direct calls versus virtual call mechanisms.

Written by the indexing model from the issue text.