c: Fix up speed up compilation of large char array initializers when not using #embed [PR117177]

Apparently my
c: Speed up compilation of large char array initializers when not using #embed
patch broke building glibc.

The issue is that when using CPP_EMBED, we are guaranteed by the
preprocessor that there is CPP_NUMBER CPP_COMMA before it and
CPP_COMMA CPP_NUMBER after it (or CPP_COMMA CPP_EMBED), so RAW_DATA_CST
never ends up at the end of arrays of unknown length.
Now, the c_parser_initval optimization attempted to preserve that property
rather than changing everything that e.g. inferes array number of elements
from the initializer etc. to deal with RAW_DATA_CST at the end, but
it didn't take into account the possibility that there could be
CPP_COMMA followed by CPP_CLOSE_BRACE (where the CPP_COMMA is redundant).

As we are peaking already at 4 tokens in that code, peeking more would
require using raw tokens and that seems to be expensive doing it for
every pair of tokens due to vec_free done when we are out of raw tokens.

So, the following patch instead determines the case where we want
another INTEGER_CST element after it after consuming the tokens, and just
arranges for another process_init_element.

2024-10-17  Jakub Jelinek  <jakub@redhat.com>

	PR c/117177
gcc/c/
	* c-parser.cc (c_parser_initval): Instead of doing
	orig_len == INT_MAX checks before consuming tokens to set
	last = 1, check it after consuming it and if not followed
	by CPP_COMMA CPP_NUMBER, call process_init_element once
	more with the last CPP_NUMBER.
gcc/testsuite/
	* c-c++-common/init-4.c: New test.