8233922: Service binding augments module graph with observable incubator modules

[Alan Bateman]

This issue concerns the interaction of service binding with incubator 
modules, a left over from JDK 9 that resurfaces with the upcoming JEP 
343 Packaging Tool (Incubator).

The summary on this issue is that service binding augments the module 
graph with the modules induced by the service-use relation. This happens 
irrespective of the incubating status of the observable modules because 
the incubating designation is a JDK rather than Java SE/specified 
concept. It shows up with module `jdk.incubator.jpackage` because this 
module wants to implement the `java.util.spi.ToolProvider` service 
interface, a service interface used by `java.base`. If service binding 
were to resolve `jdk.incubator.jpackage` then a warning would be emitted 
in all phases that java.base is resolved (so everywhere).

It's on my radar to more precisely specify service binding and also work 
out the specification changes needed to allow filtering of the observing 
modules but this is not needed at this time. Instead, we can limit the 
changes to the configuration for the boot layer as the set of observable 
modules when creating the configuration for the boot layer is not 
specified (it's up to the implementation). The change proposed here 
means that incubator modules are not candidates to add to the module 
graph during service binding for the boot layer's configuration. It has 
no impact on the general case where incubating modules may be observable 
when creating the configuration for custom layers.

While in the area, I've also fixed the existing DefaultModules test to 
allow for incubator modules as this test has been failing the jpackage 
branch. We didn't have any incubator modules in JDK 11, when the test 
was added, to notice this oversight in the test.

The webrev with the proposed changes is here. The reason that the jlink 
system modules plugin is updated is because it creates the configuration 
for the boot layer at link-time, for cases where we are skip resolution 
at run-time.
   http://cr.openjdk.java.net/~alanb/8233922/webrev/

-Alan.