OPTION_JdtDebugCompileMode has surprising effects on imports

[trancexpress]

Replace OPTION_JdtDebugCompileMode with
OPTION_IgnoreUnnamedModuleForSplitPackage, to avoid unexpected effects from the first.

What it does

How to test

Author checklist

• I have thoroughly tested my changes
• The change is following the coding conventions
• I have signed the Eclipse Contributor Agreement (ECA)

[trancexpress]

Seems to cause problems at least in: ModuleBuilderTests.test_no_conflicting_packages_for_debugger_global()

I'll see when I can look into this.

Must be done after: eclipse-jdt/eclipse.jdt.debug#261

[trancexpress]

@stephan-herrmann do you have time to look into the remaining test fail?

	public void test_no_conflicting_packages_for_debugger_global() throws CoreException {
		Hashtable<String, String> javaCoreOptions = JavaCore.getOptions();
		try {
			Hashtable<String, String> newOptions=new Hashtable<>(javaCoreOptions);
			newOptions.put(CompilerOptions.OPTION_IgnoreUnnamedModuleForSplitPackage, JavaCore.ENABLED);
			JavaCore.setOptions(newOptions);
			String[] sources = new String[] {
					"src/java/util/Map___.java",
					"package java.util;\n" +
					"abstract class Map___ implements java.util.Map {\n" +
					"  Map___() {\n" +
					"    super();\n" +
					"  }\n" +
					"  Object[] ___run() throws Throwable {\n" +
					"    return entrySet().toArray();\n" +
					"  }\n" +
					"}"
			};
			IClasspathEntry dep = JavaCore.newContainerEntry(new Path(JavaCore.MODULE_PATH_CONTAINER_ID));
			IJavaProject p1= setupModuleProject("debugger_project", sources, new IClasspathEntry[]{dep});
			p1.getProject().getWorkspace().build(IncrementalProjectBuilder.FULL_BUILD, null);
			assertNoErrors();
		} finally {
			deleteProject("debugger_project");
			JavaCore.setOptions(javaCoreOptions);
		}
	}

The error is produced by: ImportReference.checkPackageConflict(CompilationUnitScope)

There is no check anymore there, whether to produce the split package error. So it does produce the error. Is the code supposed to not run at all, or must it check if the unnamed module is part of the conflict and then (depending on the new compiler option) not report the error?

[stephan-herrmann]

@trancexpress are we ready for removing "Draft" and a final review? (Haven't yet looked at all changes).

[stephan-herrmann]

In light of eclipse-jdt/eclipse.jdt.debug#309 this change is not a good idea.

Superseded by the opposite: #2340