fix: Resolve relative dependencies before creating imports from them

[codeworrior]

TypeScript cannot recognize that a relative dependency "./library" in a module "sap/ui/unified/ColorPicker" maps to the ambient module "sap/ui/unified/library" (without import maps / package.json entries, relative import specifiers don't map to any bare modules).

By resolving relative dependencies before creating imports from them, this can be improved. As the resolution is no longer unique when "resource-roots" configuration is used, the resolution is limited to productive code. in test code, the use of "resource-roots" mappings is much more likely.

[codeworrior]

The failing tests show that there's a trade-off for this PR:

• ambient modules are now taken into account and some more issues can be detected that way
• on the other side, information from modules that are not described as ambient modules but used via relative imports is now lost (E.g. ./Metadata in the sap/ui/base/Objectin the sap.ui.core fixture project).

[codeworrior]

Maybe we should experiment with TS compiler option paths (https://www.typescriptlang.org/tsconfig/#paths). It should allow TS to find a file for a missing bare module.

[d3xter666]

Maybe we should experiment with TS compiler option paths (https://www.typescriptlang.org/tsconfig/#paths). It should allow TS to find a file for a missing bare module.

Paths seem like a promising option, but In the end it might still not be able to resolve the issue completelly.
For example, if we analyze the whole openui5 repo, then there might be numerous colliding "./library" imports that are actually libraries from different namespaces- sap.m, sap.ui.core, etc.

Maybe, we need to strive for some dynamic behaviour where the relative path resolve is based on current file/moule namespace and is available in TS only for this file/module analysis, so we don't polute TS definitions with relative paths.
Not quite sure how to achieve that for now though...