ECJ compiler with cross-compilation options launched via javax.tools API resolves types against own runtime

To reproduce, provide the following;

1. file Record.java

package com.sample;

public class Record {
}

2. file TestClass.java (notice the on-demand import)

package org.example;

import com.sample.*;

public class TestClass {
Record record;
}

3. Launch ecj on java16 and later and compile these two files with cross-compilation options
-source 8 -target 8 -bootclasspath [jdk-8-jars]

If ECJ is launched from the command line, everything compiles fine.
If ECJ is launched via javax.tools.JavaCompiler interface with compiler.getTask(...).call(), the compiler emits the "The type Record is ambiguous" error

The reason for the error is that compiler's resolution process finds the "Record" class in both "com.sample" and "java.lang" packages, although the java.lang.Record class from compiler-s own runtime should not be found when cross-compiled against jdk8 classes.

Investigation shows that the way ecj is launched matters because there are two different ways search locations are initialized:
- if launched from the command line, initialization is handled by org.eclipse.jdt.internal.compiler.batch.Main.setPaths() method
- if launched via javac.tools API, initialization is done by org.eclipse.jdt.internal.compiler.tool.EclipseCompilerImpl.handleLocations() method

the difference is that in handleLocations() the location StandardLocation.SYSTEM_MODULES is added to the search sequence no matter specified StandardLocation.PLATFORM_CLASS_PATH location or not.
see the line:
locationFiles = standardJavaFileManager.getLocation(StandardLocation.SYSTEM_MODULES);

Expected behavior:
- compilation results should not depend on the way the compiler is launched
- if bootclasspath is specified, the compiled code should not be linked against classes from the compiler's own runtime.

Affected are all ECJ versions after 4.20
See related issue
https://youtrack.jetbrains.com/issue/IDEA-317349