jshell dependence on doclint internal classes

[Jonathan Gibbons]

Kulla folk,

jshell depends on some internal doclint classes which were not intended 
for external use. This has been possible because the package 
`jdk.internal.shellsupport.doc` is colocated in the same module 
(jdk.compiler) as doclint.

We (javadoc team) are investigating the possibility of moving doclint 
into the jdk.javadoc module. To do so, we need to address the following 
usage:

$ find src/jdk.compiler/share/classes/jdk/internal -name \*.java | xargs grep doclint
src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/JavadocFormatter.java:import com.sun.tools.doclint.Entity;
src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/JavadocFormatter.java:import com.sun.tools.doclint.HtmlTag;

The use of HtmlTag is generally simple and could either be replaced with 
the use of string constants, including strings-in-switch, or by a 
trivial local enum containing just the tags of interest.

The use of Entity is more problematic. It is reasonable for the 
JavadocFormatter class to utilize the non-trivial data in Entity class. 
The proposal is to replace the doclint-internal class with public API in 
com.sun.source.util.DocTrees. It is proposed to add the following method:

     int getCodePoint(EntityTree tree)

which should be sufficient for the needs of 
JavadocFormatter.FormatJavadocScanner.visitEntity, in lines 513-538. 
Indeed, that visitEntity method should be significantly simplified with 
the use of the proposed new method.

Do these sort of changes seem reasonable, to better separate jshell from 
doclint?

-- Jon