Fix ECJ type inference error in lambda test fixtures

Add explicit type witness to Arrays.sort calls to avoid ECJ type
inference ambiguity with Comparator<? super T> wildcards. The PR's
change to use BUILD_RELEVANT_NAMESPACES in addTransitiveDependenciesWithForbiddenAccess
changes the classpath composition, exposing a stricter ECJ type
inference behavior for lambdas with explicitly typed parameters.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: vogella

apitools/org.eclipse.pde.api.tools.tests/test-builder/usage/java8/lambda/testLambdaExpression.java

@@ -27,8 +27,8 @@ public class testLambdaExpression {
 	void m1() {
 		FieldUsageClass noRef = new FieldUsageClass();
 		String[] array = {"one"};
-		Arrays.sort(array, (String s1, String s2) -> noRef.f1);
-		Arrays.sort(array, (String s1, String s2) -> FieldUsageClass.f2);
+		Arrays.<String>sort(array, (String s1, String s2) -> noRef.f1);
+		Arrays.<String>sort(array, (String s1, String s2) -> FieldUsageClass.f2);
 	}
 
 }

apitools/org.eclipse.pde.api.tools.tests/test-builder/usage/java8/lambda/testLambdaStatement.java

@@ -27,8 +27,8 @@ public class testLambdaStatement {
 	void m1() {
 		FieldUsageClass noRef = new FieldUsageClass();
 		String[] array = {"one"};
-		Arrays.sort(array, (String s1, String s2) -> noRef.f1);
-		Arrays.sort(array, (String s1, String s2) -> FieldUsageClass.f2);
+		Arrays.<String>sort(array, (String s1, String s2) -> noRef.f1);
+		Arrays.<String>sort(array, (String s1, String s2) -> FieldUsageClass.f2);
 	}
 
 }