Prefer error-verbose to error_verbose

[Akim Demaille]

If we mean to support dashes in variables names, and we do, then  
something must be changed in the way we scan variable names, as  
currently they rely on the same lexical definition of "identifier" as  
the rule symbols do.

There are several ways to do that.  One is to introduce a new token  
type, "ID_WITH_DASHES", and extend the following grammar rules:

variable:
  ID
| STRING { $$ = uniqstr_new ($1); }
;

That's straightforward.  There is one interesting question about the  
user-visible name to use for ID_WITH_DASHES.  It cannot be  
"identifier" since that's already used by ID, so should it be  
"variable", since ID_WITH_DASHES would be only used for variables?   
Not nice, we're giving some syntactic interpretation to a lexical  
entity without knowing yet how this "variable" is going to be used.   
And of course, the error message will differ depending whether there  
are dashes or not in the identifier (this is arguably a limitation in  
Bison's support for user-visible token strings, after all both ID and  
ID_WITH_DASHES could be mapped to "identifier" without any problems  
provided "identifier" is not used in the grammar itself).

I don't like too much this approach, I prefer simply welcoming dashes  
in the set of letters that can compose symbol names.  Of course we  
would have to have warnings and errors in Yacc mode, but that should  
not be hard, we certainly have one well defined point by which we  
always pass to make a symbol name.  I also like that identifiers and  
directives are only separated by %.

But what do others think?

There is one clear downside: named references.  The period is already  
causing nasty issues when reading { .. $foo.bar .. }, introducing  
dashes will not improve the situation { .. $foo-bar .. }.  I would  
stick to the principle that identifier in the action should stick to C  
symbols, that exclude dashes and periods, so this was { .. $[foo]- 
bar .. } "of course".

I have pushed my proposal (which does not include the warning) in  
candidates/define-error-verbose, whose patch is attached here.

Cheers.