Add test setup for SootUp

[smeyer198]

Add the test setup for the SootUp scope. To be consistent with the other scopes, this PR also generalizes reading the required test class files and extracting specified JDK class files and copy them to a local directory that is removed once the tests are finished

[smeyer198]

Missing tasks:

• Add phantom methods when constructing the call graphs. Currently, methods without an existing body are skipped.
• Figure out why the tests are failing that require specifc classes from the JDK. This may be caused by missing BodyInterceptors
• Disable warnings when creating the call graph when setting up SootUp

[smeyer198]

@swissiety I completed the basic test setup for SootUp. Some aspects that may be changed or improved:

• I added the feature to add explicit intialization of uninitialized fields (i.e. uninitializedField = null). This feature was missing and is required
• I extended the call graph to add edges to phantom methods if the method source cannot be resolved
• Maybe you want to take a closer look to the JimpleUpType class. I am not completely sure how we should implement the isSubtypeOf and isSupertypeOf methods. The previous implementation threw exceptions. Additionally, I don't know how to properly implement the doesCastFail method because I don't know what it is supposed to do. It is related to an option but I am not sure what the option does. Similiar to Opal, I default to false, hence, we can continue working on that option in the future
• Regarding the test setup: The current solution copies the required test and jdk class files into new temporary directories. This is mainly done because the InputLocations only provide inputs for directories. Maybe as an inspiration for SootUp: Opal allows us to instatiate a project with file arrays File[] for application and library classes. This way, one does not need to copy any files. Additionally, I am not sure what the TypeSource means: If I mark the JDK classes as Library, they don't seem to be included in the analysis, so I added them to Application too
• I configured only the TypeAssigner and BoomerangPreInterceptor as BodyInterceptors. I am not sure whether there are other interceptors that may be relevant
• SootUp constructs a Jimple code that does not allow us to use the option handleMaps because there is a bug with its implementation. This bug is a general bug and not related to SootUp itself. I opened an issue for it. Without fixing this bug, we have to exclude the KeySensitiveTest class
• Is there an option to disable warnings in SootUp when constructing the call graph? Otherwise, we should disable them ourselves

[swissiety]

• for isSuperType? etc.we should use the TypeHierarchy(viaview.getTypeHierarchy()`) which has that functionality implemented
• doesCastFail should "somehow be similiar" to isSuperType I guess.. we should investigate that
• Interceptor: as they (should) work like in Soot I assume we should configure them the same way as for Soot
• I think we can configure to disable logging for the specific classes - i.e. SootUp

[smeyer198]

Okay, I completed the subType and superType methods using the type hierarchy

• Regarding the interceptors: In Soot, we disable most transformers. Hence, I think we should keep it like now (i.e. we use only the TypeAssigner and our PreInterceptor). I think this also makes it more convenient in general because we don't enforce the usage of specific interceptors
• Reagrding the logging: I just noticed that the logging happens only in the setup, not when running Boomerang or IDEal. Hence, I would not try to override any logging configurations. This can be done by the users themselves
• Regarding the doesCastFail: This is related to the typeCheck option. As I said, I am not completely sure what it is supposed to do. There aren't any use cases or tests, too. Maybe, we can ignore it for now and figure out what the option (and other options) do and implement them in an separate issue