javasrc2cpg: improve type resolution for missing types

[johannescoetzee]

Currently, if the JavaParserSymbolSolver cannot resolve a type, javasrc2cpg gives up and does not try to use available information to infer what the missing type should be. In many cases there would be sufficient type information available to fully infer the typeFullName, so a fall-back to this should be added.

• [ ] Use import statements where available to infer missing Parameter/VarDecl types
• [ ] For unresolved method calls, use the type of the target to infer part of the methodFullName
• [ ] For unresolved method calls, use known argument types and expected return type (where this is known) to infer the rest of the methodFullName
• [ ] For unresolved arguments to resolved method calls, infer argument type from call expectations
• [ ] Be more consistent with how unresolved types are handled. Currently some types are set as <unresolved>... and others are left empty. If type info is still missing after all of the above, then we do not know the type and should leave it empty.

[mpollmeier]

probably related to this: some method fullnames are empty. E.g. for https://github.com/ShiftLeftSecurity/HelloShiftLeft:

cpg.method.internal.fullName("").code.l

  "public ModelAndView errorHtml(HttpServletRequest request)",
  "public ResponseEntity<Map<String, Object>> error(HttpServletRequest request)",
  "private HttpStatus getStatus(HttpServletRequest request)"

[johannescoetzee]

There have been various improvements to this since the issue was created and the original tasks have been addressed. We also no longer create methods with empty fullnames, instead just opting for unresolved types where information is missing.