Rename variant and lex_symbols options

[Akim Demaille]

Hi Joel!  (or whoever reads this message!)

I hope I'm not infringing too much on your user
space :)  but I'd like your opinion on the proper
names to give the %define lex_symbol and %define
variant.  They must be renamed for 2.6 to be
releasable.

We've already had a similar discussion a couple of
years ago, but I can't find the details, and don't
remember exactly the point we reached.

* variant
The point of "variant" is to allow objects (not pointers
to objects) to be used to type the symbols in the C++
LR parser.

So we have, for instance :

> %token <::std::string> TEXT;
> %token <int> NUMBER;
> 
> list:
>   /* nothing */ { /* Generates an empty string list */ }
> | list item     { std::swap ($$, $1); $$.push_back ($2); }
> ;

It does have an influence on the API, since yylval can no
longer be used "simply".  So it could be something like
api.symbols.variant, or api.values.variant...

* lex_symbols
The point here is to provide an API to build the symbols
in such a way that it is not possible to return a semantic
value incompatible with the token kind (e.g.,
[0-9]+   yylval.sval = yytext; return INTEGER;):

instead you write:

> [0-9]+   return yy::parser::make_INTEGER(text_to_int (yytext), loc);
> [a-z]+   return yy::parser::make_IDENTIFIER(yytext, loc);
> ":"      return yy::parser::make_COLON(loc);

Again, it has an influence on the API, so may
api.tokens.constructors (we already have api.tokens.prefix
which probably should have been api.token.prefix), or
api.token.object.

Both are meant to be used together.  Maybe actually I should
enforce this so that there are less combinations to check.