Fixing imports for static item completion.

[lahodaj]

Consider case like:
https://github.com/openjdk/jdk/blob/55c3e78f4ec982908e9a4b5e64b8be89717c49f4/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java#L2382

calling the code completion after .hasTag(. Given TypeTag is an enum, the CC should show all the enum constants. But, inside the VS Code, it fails to show anything.

This is (sadly) a consequence of a series of mishaps (see later), but one of them is that JavaCompletionCollector.createStaticMemberItem is using GeneratorUtilities.addImport, which itself misbehaves. But, the collector should not use this method at all: addImport does not allow to inject FQNs if needed, etc. The main proposal in this patch is to use SourceUtils.resolveImport to resolve imports for createStaticMemberItem, which adds imports as needed, and provides the simple or qualified name that should be injected into the source. resolveImport was already used on another place in the class.

The other problems I've ran into, but are not fixed by this PR:

• TextEdit.getNewText is specified to never return null, but it might return null, as there's no check when the instance is created.
• The TextEdit with the null new text is created from a ModificationResult.Difference for text removal - where the method is also specified to not return null
• GeneratorUtilities.addImports is removing package imports, intending to replace them with single-class imports, but it does not do the replacement. I think addImports should not remove package imports, unless called from OrganizeImports. Or, possibly, there should be a different entrypoint for OrganizeImports. But it seems wrong to manipulate imports in such an intrusive manner in simple addImports.

I've also fixed for I think was flipped logic for sort text and smart typing for createStaticMemberItem.

[dbalek]

Looks fine. Thanks.