[SYCL] Implement reduction properties extension

[Pennycook]

Adds support for initialize_to_identity and deterministic properties.

Since this extension is only experimental, the implementation here avoids making significant changes to reduction-related classes (e.g, reducer).

A more straightforward implementation that attaches a compile-time property list to these classes is possible, but may be considered an ABI break.

---

A note to reviewers: it occurred to me that IsDeterministicOperator<BinaryOperation> might actually be better as IsDeterministicOperator<T, BinaryOperation>, so that the implementation can infer that it's safe to use the faster reductions for certain types (e.g., int and sycl::plus<>() can safely use atomics) but I wanted to get your feedback on the proposed approach before going any further.

EDIT: To clarify, I think such changes to IsDeterministicOperator could be left until a future PR, since the behavior of the deterministic property as implemented here should match the legacy SYCL_DETERMINISTIC_REDUCTION macro. We could implement optimizations later.

[aelovikov-intel]

Any chance we can be "smart" and change

template <typename T, typename BinaryOperation>
auto reduction(T *Var, const T &Identity, BinaryOperation Combiner,
               const property_list &PropList = {}) 

to

template <typename T, typename BinaryOperation, typename PropertyListTy = property_list>
auto reduction(T *Var, const T &Identity, BinaryOperation Combiner,
               const PropertyListTy &PropList = {}) 

instead of adding a bunch of new overloads?

[Pennycook]

Any chance we can be "smart" and change

template <typename T, typename BinaryOperation>
auto reduction(T *Var, const T &Identity, BinaryOperation Combiner,
               const property_list &PropList = {}) 

to

template <typename T, typename BinaryOperation, typename PropertyListTy = property_list>
auto reduction(T *Var, const T &Identity, BinaryOperation Combiner,
               const PropertyListTy &PropList = {}) 

instead of adding a bunch of new overloads?

I'd rather keep the overloads for now, if that's okay. Because this extension is only experimental, I don't want us to make changes to the "real" reduction interface if we don't have to. Plus, if we're successful with getting compile-time properties into a future version of the SYCL specification, I expect we'll want to generate a deprecation notice for the property_list overloads, and I can't think of a way to do that without splitting things out.

[Pennycook]

@gmlueck - Could you please take a quick look at the extension specification changes here? They're just typo fixes so it hopefully shouldn't take too long to review.

[Pennycook]

@intel/llvm-gatekeepers, I think this can be merged now.