doc: java: SymbolKind, etc.

Why didn't I think about this before???  symbolName should be a method
of SymbolKind.

* data/skeletons/lalr1.java (YYParser::yysymbolName): Move as...
* data/skeletons/java.m4 (SymbolKind::getName): this.
Make the table a static final table, not a local variable.
Adjust dependencies.
* doc/bison.texi (Java Parser Interface): Document i18n.
(Java Parser Context Interface): Document SymbolKind.
* examples/java/calc/Calc.y, tests/local.at: Adjust.

TODO

@@ -1,8 +1,21 @@
 * Bison 3.6
+** Questions
+*** Java
+- Should i18n be part of the Lexer?  Currently it's a static method of
+  Lexer.
+
+- is there a migration path that would allow to use TokenKinds in
+  yylex?
+
+*** D
+- is there a way to attach yysymbol_name to the enum itself?  As we did
+  in Java.
+
+- It would be better to have TokenKind as return value.  Can we use
+  reflection to support both output types?
+
 ** Documentation
-- yyexpected_tokens/expected_tokens/expectedTokens in all the languages.
 - YYERRCODE, YYUNDEF, YYEOF
-- i18n in Java
 - symbol.type_get should be kind_get, and it's not documented.
 - YYERRCODE and "end of file" and translation
 
@@ -11,9 +24,6 @@ You can explicitly specify the numeric code for a token type...
 
 The token numbered as 0.
 
-Therefore each time the scanner returns an (external) token number,
-it must be mapped to the (internal) symbol number.
-
 ** Java: EOF
 We should be able to redefine EOF like we do in C.
 
@@ -120,11 +130,6 @@ https://www.cs.tufts.edu/~nr/cs257/archive/clinton-jefferey/lr-error-messages.pd
 https://research.swtch.com/yyerror
 http://gallium.inria.fr/~fpottier/publis/fpottier-reachability-cc2016.pdf
 
-* D
-** yylex
-It would be better to have TokenKind as return value.  Can we use reflexion
-to support both output types?
-
 * Modernization
 Fix data/skeletons/yacc.c so that it defines YYPTRDIFF_T properly for modern
 and older C++ compilers.  Currently the code defaults to defining it to