libstdc++: Work around modules issue causing hello-1 ICE [PR113710]

The forward declarations of std::get in <bits/stl_pair.h> added in
r14-8710-g65b4cba9d6a9ff are causing an ICE in the test modules/hello-1
due to what seems to be a declaration merging issue in modules.

What's happening is that in hello-1_b.C we first include <string_view>,
which indirectly includes <bits/stl_pair.h> which forms the dependent
specialization tuple_element<__i, tuple<_Elements...>> (appearing in
the signatures of some of the std::get overloads) and adds it to the
specializations table.

We then import hello which indirectly includes <tuple> (in the GMF),
within which we define a partial specialization of tuple_element with
that same template-id.  So importing hello in turn streams in this
partial specialization but we don't merge it with the previously created
dependent specialization, and we end up with two equivalent types for
this template-id with different TYPE_CANONICAL.

This patch works around this issue by adding a forward declaration of
the tuple_element partial specialization from <tuple> to <bits/stl_pair.h>
so that it appears alongside the dependent specialization of the same
template-id.  So when including <bits/stl_pair.h> we immediately register
the template-id as a partial specialization, and if we later stream in the
partial specialization the MK_partial case of trees_in::key_mergeable will
match them up.  (So perhaps a proper modules fix for this might be to make
key_mergeable try to match up a streamed in partial specialization with an
existing specialization from the table via match_mergeable_specialization.)

	PR testsuite/113710
	PR c++/113814

libstdc++-v3/ChangeLog:

	* include/bits/stl_pair.h (tuple_element): Add forward
	declaration of the partial specialization for tuple.

Reviewed-by: Jonathan Wakely <jwakely@redhat.com>