When the file name for a #include directive is the result of stringifying a
macro argument, libcpp needs to take some care to get the whitespace
correct; in particular stringify_arg() needs to see a CPP_PADDING token
between macro tokens so that it can figure out when to output space between
tokens. The CPP_PADDING tokens are not normally generated when handling a
preprocessor directive, but for #include-like directives, libcpp sets the
state variable pfile->state.directive_wants_padding to TRUE so that the
CPP_PADDING tokens will be output, and then everything works fine for
computed includes.

As the PR points out, things do not work fine for __has_include. Fix that by
setting the state variable the same as is done for #include.

libcpp/ChangeLog:

	PR preprocessor/110558
	* macro.cc (builtin_has_include): Set
	pfile->state.directive_wants_padding prior to lexing the
	file name, in case it comes from macro expansion.

gcc/testsuite/ChangeLog:

	PR preprocessor/110558
	* c-c++-common/cpp/has-include-2.c: New test.
	* c-c++-common/cpp/has-include-2.h: New test.