RulesParser.RulesParser: Parse string 'expressions'

nb: I've avoided the term "expression" since, there is only one
datatype in the rules language, thusfar, and therefore we can just call
them 'values' or 'strings'  Actually, I guess there is one other
class of expression-y construct: booleans.  But thus far, you can never
use one in place of the other; in any given context either a boolean
or a string is called for, and therefore there's no need to use such
abstract terminology as "type" or "expression" when talking about them.

Thankfully, since we have already doled out waaay more expressive power
than really was called for, mostly in the interest of creating an easily
grokked rule configuration syntax (how easy it is to actually write code
for it remains to be seen, but any experienced gentoo developer looking at
the rules files ought instantly be be able to grok 90% of their contents).

Aaanywho... whatever we want to call them, here I flesh out the
productions for right-hand-side strings, including back-quoted

Signed-off-by: Gregory M. Turner <gmt@be-evil.net>
RulesParser.RulesParser: add p_error pseudoproduction

This is required to build the parser successfully.  The rule is
currently untested and probably has bugs.

With this patch we are now able to parse any valid chain of assignment
statements:

    >>> from OverlayUpstreamTracking.RulesParser import RulesParser
    >>> rp = RulesParser()
    WARNING: Token 'TILDEEQUALS' defined, but not used
    .
    .
    WARNING: There are 32 unused tokens
    >>> prog = '''x := "\\${foo} is \\"${foo}\\".";
    ... y := "${x}";'''
    >>> print prog
    x := "\${foo} is \"${foo}\".";
    y := "${x}";
    >>> print rp.parse(prog)
    ('RULESPROGRAM', ('ASSIGN', 'x', ('STRING', ('STRINGLITERAL', '$'),
    ('STRINGLITERAL', '{foo} is '), ('STRINGLITERAL', '"'),
    ('VARIABLE-SUBSTITUTION', 'foo'), ('STRINGLITERAL', '"'),
    ('STRINGLITERAL', '.'))), ('ASSIGN', 'y', ('STRING',
    ('VARIABLE-SUBSTITUTION', 'x'))))
    >>>

    Notice the contiguous STRINGLITERAL elements in the STRINGs -- that is
    pretty dumb, I plan to find some reasonable way to have these
    automagically merged into single STRINGLITERALs.