Java: Multi-module Maven and multi-project Gradle builds with same class have only one CodeQL element

It appears multi-module Maven and multi-project Gradle builds which declare a class in the same package and with the same name in different modules / subprojects only produce one CodeQL database element for the class and its members. However that class then has more than one `getCompilationUnit()` result.

Example CodeQL query:
```ql
import java

string getProjectPath(CompilationUnit file) {
result = file.getRelativePath().regexpCapture("(.+?/).*", 1)
}

from Element e
where
e.fromSource()
and count(e.getCompilationUnit()) > 1
select e, concat(CompilationUnit c | c = e.getCompilationUnit() | getProjectPath(c), ", ")
```
[Query Console link](https://lgtm.com/query/2230210325492091599/)

This causes multiple issues:
1. Predicates such as `getAMethod()` report methods from the wrong class; e.g. when a method only exists in class of module A, module B will report it as well
2. The VSCode extension AST viewer fails to handle it correctly, showing error messages similar to "Element with id 28 is already registered" when trying to expand the "[CompilationUnit]" entry in the tree view
3. It looks like some methods (such as `InstanceInitializer`) are not shared, therefore resulting in classes which claim to have more than one `InstanceInitializer` (not to be confused with #5730)

The sanest way to solve this would probably to have separate database entries for the classes with the same name. Though I don't know how difficult it would be to adjust the extractor accordingly.

Note also that while this mostly affects test modules / subprojects and therefore might not have high priority, it also affects non-test modules, e.g. for JLine 3 ([Query Console link](https://lgtm.com/query/6613935408546989327/)) where the source code of the other modules seems to be copied to the `jline/` module, therefore existing in two modules.