Add context to aliases in configuration

[emilienlemaire]

While working on configurations with @nberth, we discoverd that rules like reserved: ALIAS*=CONTEXTUAL-WORD in configuration files, the context sensitivity of CONTEXTUAL-WORD was never reported to the aliases. A small example with the following code:

       IDENTIFICATION   DIVISION.
       PROGRAM-ID.      prog.
       DATA             DIVISION.
       WORKING-STORAGE  SECTION.
       01  BYTE-LENGTH  PIC 9.
       01  X            CONSTANT AS BYTE-LENGTH OF BYTE-LENGTH.
       PROCEDURE        DIVISION.
           MOVE X TO BYTE-LENGTH.
           DISPLAY BYTE-LENGTH NO ADVANCING
           END-DISPLAY.
           STOP RUN.

If we run the compiler with reserved: XX*=BYTE-LENGTH and replace all BYTE-LENGTH in the code with XX we get the following errors:

test.cob:5: error: syntax error, unexpected BYTE-LENGTH
test.cob:6: error: syntax error, unexpected BYTE-LENGTH
test.cob:6: error: constant item 'X' requires a VALUE clause
test.cob:8: error: syntax error, unexpected BYTE-LENGTH
test.cob:9: error: syntax error, unexpected BYTE-LENGTH, expecting (

when the file is expected to compile. After the changes introduced in this PR we can compile with contextual aliases.

This PR also fixes a small error in config/ibm.conf

[nberth]

       01  X            CONSTANT AS BYTE-LENGTH OF BYTE-LENGTH.

@GitMensch Most documentations seem to make BYTE-LENGTH sensitive in "constant entry", which I guess in principle spans from the level (01 above) to the terminating .. In practice, restricting "constant entry" to start right after CONSTANT makes sense, however I'm wondering whether the second BYTE-LENGTH above is actually legitimate.

[GitMensch]

It is valid because the only thing that may be used there is a data-name, and therefore the data-names must be inspected. Note that GnuCOBOL has (with the default std) uses context-sensitivity quite often and "with reduced scope", which enables it to compile a lot of different dialects by limiting their "special" reserved words to be tokenized as reserved word where it actually may be used as this - otherwise it is recognized as user-defined word (mostly data-name or label-name)

[GitMensch]

@nberth : feel free to commit "upstream"

[GitMensch]

Now upstream - thanks again.