[diff.expr] Include conversions involving pointers to cv void in the changes

[eisenwave]

This fixes two issues:

1. Conversions from const void* to const int* are implicit in C as well, but they are missing from the C annex. I don't think this needs a CWG issue.

2. The notation referring to void* in this area is weird. Example of better notation:

   draft/source/expressions.tex

   Lines 1049 to 1053 in ca77cdb

   	\pnum
   	A prvalue of type ``pointer to \cv{} \tcode{T}'', where \tcode{T}
   	is an object type, can be converted to a prvalue of type ``pointer to
   	\cv{} \keyword{void}''.
   	The pointer value\iref{basic.compound} is unchanged by this conversion.

   
   Basically, we don't use "code spellings" in code wording, but prefer the "quoted" type notation.

[jensmaurer]

While I've approved the change, I'm asking myself whether the "cv" matter for this example-style highlight of a C difference is actually important. (We don't say that the pointer-to-object type must be similarly cv-qualfiied.)

@tkoeppe

[eisenwave]

I was under the impression that we try to describe differences from C exhaustively in [diff]. void*-to-object-type conversions would only be an example, not a complete description of the change.

Please correct me if I've misunderstood the point of [diff].

We don't say that the pointer-to-object type must be similarly cv-qualified.

"Object type" includes cv-qualified types, so saying that converting from const void* to "an object type" requires a cast is correct. Converting to int* would drop cv-qualification and converting to const int* would be disallowed as well, for the reason we are pointing out in [diff]. Anyhow, I don't think it would improve the change further if we pointed out a possible cv-qualification of the destination object type.

[jensmaurer]

CWG 2025-10-24: Approved direction.