Is it valid to map a system SVM allocation?

Is it valid to map a system SVM allocation using [clEnqueueSVMMap](https://registry.khronos.org/OpenCL/specs/unified/html/OpenCL_API.html#clEnqueueSVMMap)?

Doing this would be a little silly, since there is no need to map a system SVM allocation, but should this be an error?

The current spec does not clearly say whether this is allowed or not, but it is implied in the description of _svm_ptr_:
> If svm_ptr is allocated using [clSVMAlloc](https://registry.khronos.org/OpenCL/specs/unified/html/OpenCL_API.html#clSVMAlloc) then it must be allocated from the same context from which command_queue was created. Otherwise the behavior is undefined.

There is no documented error condition for this case, either, though there is also no documented error condition for the "must be allocated from the same context" requirement above, either, so it could just be that this isn't very well thought out.

I'm going to label this issue with the cl_khr_unified_svm label since the resolution will affect the extension, specifically whether CL_SVM_CAPABILITY_HOST_MAP_KHR‎ is included in CL_SVM_TYPE_MACRO_SYSTEM_KHR, though this clarification affects core system SVM and is not specific to the unified SVM extension.

I think I have a slight leaning towards disallowing system SVM from clEnqueueSVMMap, since it's a weird case and I don't think it's well-tested, but it's just a slight leaning.

Start by reading the linked clEnqueueSVMMap and clSVMAlloc specification sections, then compare core system SVM behavior with the cl_khr_unified_svm extension and its CL_SVM_CAPABILITY_HOST_MAP_KHR and CL_SVM_TYPE_MACRO_SYSTEM_KHR references. Done means the allowed behavior or error condition is resolved and the affected specification text and extension impact are identified.

Written by the indexing model from the issue text.