add optional semicolon to cfg

[bryankenote]

Fixes #70

[bryankenote]

Seeing these errors when trying to gen the lexer or parser

Some problems were found with the configuration of task ':generateLexer' (type 'GenerateLexerTask').
  - In plugin 'org.jetbrains.grammarkit' type 'org.jetbrains.grammarkit.tasks.GenerateLexerTask' property 'source' doesn't have a configured value.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.
BUILD FAILED in 62ms
1 actionable task: 1 executed

Some problems were found with the configuration of task ':generateParser' (type 'GenerateParserTask').
  - In plugin 'org.jetbrains.grammarkit' type 'org.jetbrains.grammarkit.tasks.GenerateParserTask' property 'parserFile' doesn't have a configured value.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.
> Get more help at https://help.gradle.org.
BUILD FAILED in 60ms
1 actionable task: 1 executed

[jzbrooks]

Early on I tried using the grammar kit's grade plugin to do that generation. IIRC, at some point or other those tasks even ran automatically during the build so generated code was always ephemeral, which was nice. Memory is fuzzy but I bailed on that because the plugin didn't support some features of grammar kit. #1 (comment) The bespoke lexer generator task (generateFsdLexer) is still in there.

./gradlew tasks is misleading. It might be worthwhile to remove the grammar kit plugin from the build so it doesn't add those tasks to the project.

I typically used the grammar kit plugin in IntelliJ to regenerate the lexer and parser code.

---

You're probably going to need to update _FsdLexer.flex also. It annoyed me that the lexer was so involved, but it was the best way I could come up with to correctly tokenize method as a keyword in some syntactical contexts and as an annotation parameter name elsewhere (the HTTP annotation, I think).

[jzbrooks]

--- a/src/main/kotlin/io/github/facilityapi/intellij/fsd.bnf
+++ b/src/main/kotlin/io/github/facilityapi/intellij/fsd.bnf
@@ -42,8 +42,7 @@
 
 definition ::= (attribute_list* service_spec) markdown_remarks*
 
-service_spec ::= service identifier service_items { pin=1 }
-service_items ::= ('{' decorated_service_item* '}') | decorated_service_item
+service_spec ::= (service identifier ';' decorated_service_item*) | (service identifier '{' decorated_service_item* '}') { pin=1 }

Will probably need something like this.

You get a good deal of control around how IntelliJ should handle invalid parser states, which is helpful for error messages in the editor. It definitely had some room for improvement before, but it's something else you might consider. That's what the pin and recoverWhile bits are about.

[bryankenote]

This still doesn't account for markdown after the service body when braces are not used. This is tricky since rather than looking for both service member items and markdown items simultaneously, we look for only service member items then only markdown items when the service body is finished. The lexer works when curly braces are used because it knows when the service body is finished when it sees the right curly brace. This has been nuanced in the other parsers as well.

[bryankenote]

4d03012 Allows markdown to be lexicalized but the parser is having trouble with the first markdown header it sees.

Adding lookahead in the parser for markdown fixes this but then breaks at the end of the file.

(';' decorated_service_item* &markdown_remarks)