Fix depth-first search for Java 9 modules

To compute modules to be added to compilation roots in
JavaModuleGraph.getAllDependencies, we should look not only for
transitive requirements of root modules, but for transitive requirements
of _root modules' requirements_. The same logic applies to
JavaModuleGraph.reads. In other words, when looking for a path in the
module graph between two modules, the first edge's transitiveness
doesn't matter, but all other edges after the first must be transitive.

There was also a stupid bug in dfs in
JavaModuleGraph.getAllDependencies: we continued the DFS only if the
module _was not_ added to the "visited" set ("add" returns true if the
element was added successfully)

 #KT-18598 In Progress

compiler/testData/javaModules/nonTransitiveDoesNotAffectExplicitDependency/moduleA/a/A.java

@@ -0,0 +1,3 @@
+package a;
+
+public class A {}

compiler/testData/javaModules/nonTransitiveDoesNotAffectExplicitDependency/moduleA/module-info.java

@@ -0,0 +1,3 @@
+module moduleA {
+    exports a;
+}

compiler/testData/javaModules/nonTransitiveDoesNotAffectExplicitDependency/moduleB/module-info.java

@@ -0,0 +1,3 @@
+module moduleB {
+    requires transitive moduleA;
+}

compiler/testData/javaModules/nonTransitiveDoesNotAffectExplicitDependency/moduleC/module-info.java

@@ -0,0 +1,3 @@
+module moduleC {
+    requires moduleB;
+}

compiler/testData/javaModules/nonTransitiveDoesNotAffectExplicitDependency/moduleD.txt

@@ -0,0 +1 @@
+OK

compiler/testData/javaModules/nonTransitiveDoesNotAffectExplicitDependency/moduleD/module-info.java

@@ -0,0 +1,4 @@
+module moduleD {
+    requires moduleC;
+    requires moduleB;
+}

compiler/testData/javaModules/nonTransitiveDoesNotAffectExplicitDependency/moduleD/usage.kt

@@ -0,0 +1,5 @@
+import a.A
+
+fun usage(): String {
+    return A().toString()
+}