parser.yy: remove STRING_IDENTIFIER token

parser.yy: remove STRING_IDENTIFIER token

A STRING_IDENTIFIER always was a special case of a MARKUP_IDENTIFIER
without being treated equally at top level.  That led to craziness
like

xxx=\markup "test"
\xxx

being invalid, while

xxx=\markup \italic "test"
\xxx

was valid code.  This change just removes the STRING_IDENTIFIER
category altogether.  Where it was used previously, MARKUP_IDENTIFIER
is accepted now syntactically, and where the semantics indeed require
a plain string, an error is generated explicitly in the action instead
of leaving it to the parser to complain about bad grammar.

[lemzwerg, 2012-09-22 15:20:21]

LGTM

[joeneeman, 2012-09-26 00:03:19]

lgtm

[janek, 2012-09-26 05:35:16]

David wrote:
> ...and where the semantics indeed require a plain string,
> an error is generated explicitly in the action instead
> of leaving it to the parser to complain about bad grammar.

I'm not sure i understand.  Does this mean that in some situations there will be
errors that were not present before this change?  I.e, will something stop
working?
I guess an example should be enough for me to understand.

thanks,
Janek

[dak, 2012-09-26 06:58:12]

On 2012/09/26 05:35:16, janek wrote:
> David wrote:
> > ...and where the semantics indeed require a plain string,
> > an error is generated explicitly in the action instead
> > of leaving it to the parser to complain about bad grammar.
> 
> I'm not sure i understand.  Does this mean that in some situations there will
be
> errors that were not present before this change?  I.e, will something stop
> working?

No.  The error messages and recovery will just be different.  When the parser
proper detects something that it can't use in its current state, it throws a
cryptic error message and starts throwing material away until it thinks it can
reasonably recover.

After the change, the parser proper accepts non-trivial markups where only a
string would be allowed, and the code executed on behalf of the parser will
throw the error instead without aborting.

In short, instead of a cryptic error message and dubious error recovery, the
user gets a human-understandable error message and a recovery more likely not to
cause follow-up errors.

This is for the case where things were working fine previously.  As mentioned in
the issue description, there were several situations where things broke totally
counterintuitively (namely where markups were accepted only when they consisted
of non-trivial strings, but plain strings were rejected).

In other words: after contemplating your review, I don't see that the countdown
should be affected, but if you want to suggest a rewording of the commit message
soonish, I can of course incorporate it.

A code comment to that effect does not make all that much sense in comparison
since there is little point in writing a comment for the replacement of code
that is not even there anymore when the replacement is, in itself, quite
self-explanatory.

[janek, 2012-09-26 07:23:38]

On Wed, Sep 26, 2012 at 8:58 AM,  <dak@gnu.org> wrote:
> In short, instead of a cryptic error message and dubious error recovery,
> the user gets a human-understandable error message and a recovery more
> likely not to cause follow-up errors.

Ok.  I supposed this was the case, but wanted to be sure.  I don't
think commit message needs rewording.
Thanks for explanation!
Janek