[SYCL] Add group algorithm constraints (#2462)

is_native_function_object proved too difficult to implement and use in a
practical way.  Replacing it with constraints makes the behavior of group
algorithms more predictable and enables users to detect which type combinations
are supported at compile-time.

Replacing several usages of static_assert with constraints will also be useful in
ensuring that group algorithms are not considered during overload resolution
if the first argument is an execution policy rather than a group or sub_group.

While updating the traits to use is_pointer I realized that several functions
would only support multi_ptr because they used Ptr::element_type.  This is now
fixed, by using remove_pointer instead.

Signed-off-by: John Pennycook <john.pennycook@intel.com>

Author: Pennycook

sycl/doc/extensions/GroupAlgorithms/SYCL_INTEL_group_algorithms.asciidoc

@@ -131,8 +131,6 @@ New function objects without {cpp} standard library equivalents are defined in t
 |+T operator(const T&, const T&) const+ applies +std::greater+ to its arguments, in the same order, then returns the greater argument unchanged.
 |===
 
-Function objects supported by the group algorithms library can be identified using the +cl::sycl::intel::is_native_function_object+ and +cl::sycl::intel::is_native_function_object_v+ traits classes.
-
 === Functions
 
 The group algorithms library is based on the algorithms library described in Section 28 of the {cpp}17 standard.  The syntax and restrictions are aligned, with two notable differences: the first argument to each function is a group of work-items, in place of an execution policy; and pointers are accepted in place of iterators in order to guarantee that address space information is visible to the compiler.
@@ -145,6 +143,8 @@ Using functions from the group algorithms library inside of a kernel may introdu
 
 It is undefined behavior for any of these functions to be invoked within a +parallel_for_work_group+ or +parallel_for_work_item+ context, but this restriction may be lifted in a future version of the proposal.
 
+A number of the restrictions regarding the types of parameters that are acceptable for each algorithm must implemented as constraints: group arguments must be of a supported group class type; binary operations must be one of the group algorithms function objects; pointer arguments must be pointers to fundamental data types; and value arguments must be scalar fundamental data types (or vectors of those types).
+
 ==== Vote
 
 |===
@@ -262,6 +262,11 @@ None.
 //*RESOLUTION*: Not resolved.
 //--
 
+. How should `is_native_function_object` work?  Does it represent what is minimally required by the specification, or what the implementation really supports?
+--
+*RESOLUTION*: The `is_native_function_object` trait has been removed.  It proved too difficult to implement something that returned sensible values for transparent function objects (e.g. `std::plus<void>`) that did not also require checking additional traits for each individual group algorithm.  Requiring the user to implement their own checks based on type requirements outlined in the specification would make it significantly harder for implementers to extend the algorithms to types and function objects beyond what is specified.  Using constrained forms of the algorithms instead allows a user to determine whether an implementation of a particular algorithm exists using the C++ detection idiom.
+--
+
 == Revision History
 
 [cols="5,15,15,70"]
@@ -270,6 +275,7 @@ None.
 |========================================
 |Rev|Date|Author|Changes
 |1|2020-01-30|John Pennycook|*Initial public working draft*
+|2|2020-09-10|John Pennycook|*Remove is_native_function_object and clarify which requirements are constraints*
 |========================================
 
 //************************************************************************