<tuple>: Can we eliminate _Tuple_val?

[StephanTLavavej]

_Tuple_val deals with uses-allocator construction:

STL/stl/inc/tuple

Lines 158 to 182 in 957fe99

	template <class _Ty>
	struct _Tuple_val { // stores each value in a tuple
	constexpr _Tuple_val() : _Val() {}
	template <class _Other>
	constexpr _Tuple_val(_Other&& _Arg) : _Val(_STD forward<_Other>(_Arg)) {}
	template <class _Alloc, class... _Other, enable_if_t<!uses_allocator_v<_Ty, _Alloc>, int> = 0>
	_Tuple_val(const _Alloc&, allocator_arg_t, _Other&&... _Arg) : _Val(_STD forward<_Other>(_Arg)...) {}
	template <class _Alloc, class... _Other,
	enable_if_t<conjunction_v<uses_allocator<_Ty, _Alloc>,
	is_constructible<_Ty, allocator_arg_t, const _Alloc&, _Other...>>,
	int> = 0>
	_Tuple_val(const _Alloc& _Al, allocator_arg_t, _Other&&... _Arg)
	: _Val(allocator_arg, _Al, _STD forward<_Other>(_Arg)...) {}
	template <class _Alloc, class... _Other,
	enable_if_t<conjunction_v<uses_allocator<_Ty, _Alloc>,
	negation<is_constructible<_Ty, allocator_arg_t, const _Alloc&, _Other...>>>,
	int> = 0>
	_Tuple_val(const _Alloc& _Al, allocator_arg_t, _Other&&... _Arg) : _Val(_STD forward<_Other>(_Arg)..., _Al) {}
	_Ty _Val;
	};

However, I believe that it would be possible to fuse this behavior into tuple itself, avoiding this extra object. That could improve throughput, and generally simplify tuple's representation (at the cost of more tuple constructor complexity, but that battle has been thoroughly lost).

In theory, I believe we could do this without breaking bincompat, but this would be a fairly significant change, so it's probably vNext.

vNext note: Resolving this issue will require breaking binary compatibility. We won't be able to accept pull requests for this issue until the vNext branch is available. See #169 for more information.