[PATCH] more sparse fixes (body parsing, beginning of ## handling)

[PATCH] more sparse fixes (body parsing, beginning of ## handling)

> 	1) no ## in the beginning or end of body. [6.10.3.3(1)]
> It's a warning, recovery consists in dropping them at #define time.

Fixed in the patch I'm testing, and I was wrong about proper recovery -
better ignore the entire definition than go on with mangled one.

> 	2) ## that comes from argument does *not* have a special meaning;
> only one from the body does. [6.10.3.3(3)]

Fixed.

> 	3) assuming left-to-right order of evaluation for ## (we are free
> to choose any [6.10.3.3(3)] and left-to-right is much easier when we get
> to merging tokens), if ## immediately follows another ## it can be treated
> as not having a special meaning (it will be merged with whatever precedes
> the first one and even if result of merge will be "##", it won't have a
> special meaning).  IOW, in
> 	a ## b ## ## c ## ## ## d
> the 1st, 2nd, 4th and 6th ## will concatenate; 3rd and 5th ones will be
> merge arguments and won't merge anything themselves.

Fixed.  The rest is not - it will be a separate patch.  BTW, there's another
couple of bugs - see preprocessor9.c and preprocessor10.c for the stuff that
triggers them.

Parsing of macro bodies should be OK by now; the only missing check is
"the only place where __VA_ARGS__ can occur is in the body of macro with
argument list ending on ellipsis" and that will be dealt with later.

We get three new kinds of tokens - TOKEN_QUOTED_ARGUMENT (unexpanded arguments
next to ##), TOKEN_STR_ARGUMENT (#<argument>) and TOKEN_CONCAT (concatenation
operator).  When we go through the body of macro at #define time, we
	a) decide which ## will be operators there (see (3) above) and set
the type of those to TOKEN_CONCAT; retokenize() is looking for that
token_type() now instead of doing match_op().
	b) collapse OP[#] IDENT[argument] to a single token -
STR_ARGUMENT[argnum].  expand_arguments() looks for that token type instead
of messing with match_op() + check that the next one is an argument.
	c) mark the rest of arguments either as QUOTED_ARGUMENT or
MACRO_ARGUMENT, depending on whether they have a concatenation as neighbor
or not; expand_arguments() looks for that to decide if expand_one_arg()
should do expansion when subsitituting (instead of messing with checking
neighbors).

	All that stuff is done in one pass and comes pretty much for free -
see handle_define() for details.  And we get a nice payoff at expansion
time for that (will get more when we get to collecting the information on
arguments uses).

preprocessor{8,9,10}.c added; the first one shows the stuff fixed by
now; other two are still not handled correctly.

I don't see any regression - neither on validation/* stuff nor on full
kernel build.