<Swing Dev> RFR: 8167182: Exported elements referring to inaccessible types in jdk.accessibility

[Phil Race]

Bug : https://bugs.openjdk.java.net/browse/JDK-8167182
Webrev: http://cr.openjdk.java.net/~prr/8167182/

There are three fields exposed in the accessibility docs which are of types
that are not exported :
http://download.java.net/java/jdk9/docs/jre/api/accessibility/jaccess/spec/com/sun/java/accessibility/util/AWTEventMonitor.html#awtListener
http://download.java.net/java/jdk9/docs/jre/api/accessibility/jaccess/spec/com/sun/java/accessibility/util/SwingEventMonitor.html#swingListener
http://download.java.net/java/jdk9/docs/jre/api/accessibility/jaccess/spec/com/sun/java/accessibility/util/AccessibilityEventMonitor.html#accessibilityListener

These fields are not intended for client use.
The first has been deprecated since JDK 8 under
https://bugs.openjdk.java.net/browse/JDK-8007499
and is not used by the implementation - and is documented as such.

The other two are also package private types which external code
could use only via enabling access using core reflection.
Furthermore those types - which are nested classes - are commented
as being only intended to be used inside the containing class.


Since jigsaw (the module system) will make these fields wholly unusable,
we should either remove them from the API, or promote them to public.
Since the latter option was never intended or not useful, instead
the fix is to (effectively) remove these fields by making them private.
For the first it is more of a delete and rename but the result is the same.

In addition, the 12 other fields updated in 8007499 and which are of 
public types
are updated as being "forRemoval". They were deprecated in 8, but this 
signals
a clear intention to remove these in JDK 10. A bug to do so will be 
filed once
this webrev (and a CCC) are approved to proceed that way.
These 12 "forRemoval"s are not strictly required in this fix but since
the other (non-public) one is being removed it seems a good opportunity
to do that too.
A possibility exists to go even further and remove them immediately is 
theoretically
available since they have already been deprecated for a major release and
these are NOT "SE" APIs anyway - they are JDK scope utility classes.
I am open to that if there are strong views for it and CCC will approve.

-phil.