Introduce variadic constructor for key_matching join_node

[kboyarinov]

No description provided.

[kboyarinov]

Introducing this constraint changes can change the behavior for the existing code.
The design of the key_matching join_node implies that the number of argument is equivalent to the number of elements in the tuple.
oneTBB implementation generates a compile-time error if it is not the case. With this constraint, this overload would not participate in overload resolution, that will be different compiler-time error in most cases.

[kboyarinov]

If we consider adding this constructor as a breaking change, the alternative is to keep the "old" set of constructors and introduce the variadic constructor to handle cases when number of elements is more than 10.

Existing constructors will match better for 2-10 arguments and the old behavior is guaranteed to be preserved.

But on the other hand, a set of existing constructors will be generated from a variadic by the compiler and the only difference in the behavior is the constraint (that can be omitted if we consider it breaking).

[kboyarinov]

As we discussed, the current definition of constructors in the specification is incorrect, as the only working scenario occurs when the number of arguments exactly matches the number of elements in the tuple.

The existing oneTBB implementation results in compilation error when there is a mismatch.

A variadic constructor without constraints would not introduce breaking changes but it would also not resolve the issue described above.
Consider the following example.
In both the old and new versions, the second std::is_constructible is true, but the actual constructor cannot be invoked.

When the constraint is added (see the same example compiled with -DADD_CONSTRAINT), std::is_constructible returns a value that accurately reflects the validity of the constructor.

The same constructor cannot be implemented using std::index_sequence (as in blocked_nd_range), because we cannot generate exactly N arguments of a template type. blocked_nd_range generates N arguments of the known type blocked_range.
Therefore, I believe specifying the constructor as proposed is reasonable.
@akukanov, @vossmjp, what do you think?