Enable zip_iterator to satisfy C++20 std::input_iterator constraint

[mmichel11]

Currently with C++20, oneapi::dpl::zip_iterator cannot satisfy the C++20 std::input_iterator constraint due to it's failure to satisfy std::indirectly_readable which requires that the iterator's value and reference types have a common reference.

To resolve this issue, we specialize std::basic_common_reference for oneapi::dpl::__internal::tuple to recursively fetch the common reference types of each corresponding tuple element in the input tuples.

Furthermore, we currently use std::tuple in the internal zip_forward_iterator. In our internal use case, this becomes problematic when oneapi::dpl::__internal::tuple is nested inside std::tuple and we attempt to find common reference types. This can be produced with transform_unary.pass and transform_binary.pass with the TBB backend, where we meet compile errors such as the following:

no type named 'type' in 'std::common_reference<std::tuple<oneapi::dpl::__internal::tuple<const int &>, oneapi::dpl::__internal::tuple<int &>> &&, std::tuple<oneapi::dpl::__internal::tuple<int>, oneapi::dpl::__internal::tuple<int>> &>'
 3616 |     using common_reference_t = typename common_reference<_Tp...>::type;

To resolve such errors, I have switched zip_forward_iterator to use the internal tuple implementation in a manner consistent with zip_iterator.