[clang] [clang][SPIRV] Remove volatile variants of GenericCastToPtr* built-ins (PR #146298)

[Wenju He via cfe-commits]

================
@@ -93,16 +73,6 @@ __SPIRV_BUILTIN_ALIAS(__builtin_spirv_generic_cast_to_ptr_explicit)
 __private const void *
 __spirv_GenericCastToPtrExplicit_ToPrivate(__generic const void *,
                                            int) __SPIRV_NOEXCEPT;
-extern __SPIRV_overloadable
-__SPIRV_BUILTIN_ALIAS(__builtin_spirv_generic_cast_to_ptr_explicit)
-__private volatile void *
-__spirv_GenericCastToPtrExplicit_ToPrivate(__generic volatile void *,
-                                           int) __SPIRV_NOEXCEPT;
-extern __SPIRV_overloadable
-__SPIRV_BUILTIN_ALIAS(__builtin_spirv_generic_cast_to_ptr_explicit)
-__private const volatile void *
-__spirv_GenericCastToPtrExplicit_ToPrivate(__generic const volatile void *,
-                                           int) __SPIRV_NOEXCEPT;
----------------
wenju-he wrote:

> > In such case, any built-in that uses the pointer arg will have the same issue,
> 
> Not sure what you mean. 

I mean the case that the input pointer to builtin is already volatile, e.g. `test2` shown below. Suppose the pointer parameter of __spirv_ocl_vloadn_Rint2 isn't qualified with volatile.
Before this PR,
```
void test1(int *p) {
  __spirv_GenericCastToPtrExplicit_ToPrivate(p); // const-cast not needed
  __spirv_ocl_vloadn_Rint2(1, p); // const-cast not needed
}
void test2(volatile int *p) {
  __spirv_GenericCastToPtrExplicit_ToPrivate(p); // const-cast not needed
  __spirv_ocl_vloadn_Rint2(1, p); // const-cast needed
}
```
after this PR,
```
void test1(int *p) {
  __spirv_GenericCastToPtrExplicit_ToPrivate(p); // const-cast not needed
  __spirv_ocl_vloadn_Rint2(1, p); // const-cast not needed
}
void test2(volatile int *p) {
  __spirv_GenericCastToPtrExplicit_ToPrivate(p); // const-cast needed   <-- changed
  __spirv_ocl_vloadn_Rint2(1, p); // const-cast needed
}
```
I mean after this PR __spirv_GenericCastToPtrExplicit_ToPrivate will behave the same as other built-in that uses pointer argument regarding whether a const-cast is needed. So the casting is a general issue.
If we keep volatile variant of __spirv_GenericCastToPtrExplicit_ToPrivate, does it mean we'll add volatile overload for all built-ins that has pointer parameter?

> Did you mean the returned value ?
> a cast on the return type will usually be required

Cast on return value is only need for const, but not needed for volatile, right? I mean a non-volatile return value can be implicitly converted to a volatile value.

> I don't have strong opinion

Me neither. It is just we probably need to find a correct way to handle the builtin declarations.

https://github.com/llvm/llvm-project/pull/146298