Here we're incorrectly rejecting the first type-requirement at parse
time with

  concepts-requires35.C:14:56: error: ‘typename A<T>::B’ is not a template [-fpermissive]

We also incorrectly reject the second type-requirement at satisfaction time
with

  concepts-requires35.C:17:34: error: ‘typename A<int>::B’ names ‘template<class U> struct A<int>::B’, which is not a type

and similarly for the third type-requirement.  This seems to happen only
within a type-requirement; if we instead use e.g. an alias template then
it works as expected.

The difference ultimately seems to be that during parsing of a using-decl,
we pass check_dependency_p=true to cp_parser_nested_name_specifier_opt
whereas for a type-requirement we pass check_dependency_p=false.
Passing =false causes cp_parser_template_id for the dependently-scoped
template-id B<bool> to create a TYPE_DECL of TYPENAME_TYPE (with
TYPENAME_IS_CLASS_P unexpectedly set in the last two cases) whereas
passing =true causes it to return a TEMPLATE_ID_EXPR.  We then call
make_typename_type on this TYPE_DECL which does the wrong thing.

Since there seems to be no justification for using check_dependency_p=false
here, the simplest fix seems to be to pass check_dependency_p=true instead,
matching the behavior of cp_parser_elaborated_type_specifier.

	PR c++/110927

gcc/cp/ChangeLog:

	* parser.cc (cp_parser_type_requirement): Pass
	check_dependency_p=true instead of =false.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp2a/concepts-requires35.C: New test.

(cherry picked from commit 63bd36be)