Misused EOF causes ANTR4 confusion: possibly detect and report instead.

[SimonStPeter]

In issue #1113 @jimidle pointed out the flaw as being an EOF used in a rule which was called from elsewhere. This was a simple oversight by me, not a misunderstanding of how to use EOF.
Perhaps antlr can check for this? Suggestion:

1. ensure EOF occurs in exactly one rule
2. that rule is not called recursively (it can be called by other rules as this is reasonable parse: getheader getbody getpostscript ; where getpostscript can contain the EOF).
   Maybe this will prove too constraining, I don't know.

[sharwell]

The specific analysis of interest would be detecting cases where a non-EOF transition can appear after an EOF transition (in the follow set). However, even if detected this is not necessarily an error (see below).

Note to potential implementers: I've noticed some anomalies in the LL(1) static analysis so I'm not sure the existing code can be used as-is for this purpose.

Interesting additional things to note:

1. EOF can occur in more than one rule

2. EOF can appear in the middle of certain rules, and does not have to be the last item in a rule in all cases, such as the following (from TemplateLexer.g4):

   TemplateExpression_STRING
       :   '"' (~('"' | '\\') | '\\' (. | EOF))* '"' -> type(STRING)
       ;

   Note: The previous rule is actually not what was intended in that grammar. The use of EOF was intended to allow the rule to end with '"'? for improved error recovery, although and even better approach using multiple rules can be seen here (and throughout that grammar).

3. Multiple EOFs can appear in a row, as in Treat EOF transitions in the ATN as epsilon transitions... #531, Add unit tests for double EOF transition handling #534, Add error for EOF transition reachable in closure from itself #535, Multiple EOF #537, Remove comment that was only meant for testing #539

[parrt]

@sharwell can you remember what the LL(1) anomalies were related to? I can poke around.