Remove use of inheritance from parallel-for bricks in SYCL backend

[mmichel11]

This PR addresses #2023.

In #1976, parallel-for bricks were redesigned to have an inheritance relationship with a either a scalar or vector tuning base class in order to inherit compile-time tuning constants. This came with a downside of adding the user-provided range types to the class template of parallel-for bricks, complicating usage from the caller side as more templates must be provided when creating a brick.

This PR removes the use of inheritance from parallel-for bricks along with the range class templates with the following approach:

• Each parallel-for brick defines two compile-time boolean constants, __can_vectorize and __can_process_multiple_iters.
• The parallel-for SYCL implementation makes use of a new class __pfor_params which queries the brick's static members to define vectorization and iters per item tuning parameters.
• An instance of __pfor_params is passed to the brick when invoking the function call operator which includes vector sizes and whether vectorization should be enabled.

Additionally, the __scalar_path_impl, __vector_path_impl, and dispatch operator() design of the bricks have been replaced with two operator() definitions using SFINAE to define scalar and vector implementations dependent on whether the provided parameter instance is vectorizable.