Minor fail in realfailN scanner rules

While fooling with John Naylor's ecpg lexer sync patch, my attention
was drawn to the "realfail1" flex rule, which triggers when we see
digits immediately followed by "e", but no exponent after that:

{realfail1} {
/*
* throw back the [Ee], and treat as {decimal}. Note
* that it is possible the input is actually {integer},
* but since this case will almost certainly lead to a
* syntax error anyway, we don't bother to distinguish.
*/
yyless(yyleng - 1);
SET_YYLLOC();
yylval->str = pstrdup(yytext);
return FCONST;
}

I think that code and comment are mine, but I realized that it's overly
optimistic to suppose that the situation can't happen. Consider

SELECT 42efoo, 45 ebar;
efoo | ebar
------+------
42 | 45
(1 row)

The first target item is lexed as FCONST then IDENT because of what
realfail1 has done, while the second one is lexed as ICONST then IDENT.

This is not great. It happens to work anyway -- that is, the first
column is deemed to be int4 not numeric -- because make_const() is very
paranoid about what it might find in a T_Float constant. But it might
well be that there are other syntactic contexts in which returning FCONST
would result in parse errors or unexpected behavior.

Fortunately, this doesn't really take any extra code to fix; we can
do something like the attached. psql and ecpg should be corrected
to match, although it's certainly just cosmetic for psql, and probably
also for ecpg.

regards, tom lane