Disable ReflectionAllocationsAnalysis for TypeBasedPointsTo key

[johannesduesing]

As mentioned in #357 the ReflectionAllocationsAnalysisScheduler should not be executed with the TypeBasedPointsToCallGraphKey, but it should be run for all other implementations of PointsToCallGraphKey. This PR proposes one possible solution for the issue - i am however open for discussion, there are many ways this could be realized.

This PR moves the ReflectionAllocationsAnalysisScheduler into a separate configuration section, which is not loaded by the PointsToCallGraphKey trait, but instead by the new and more specific trait AllocationSiteBasedPointsToCallGraphKey extends PointsToCallGraphKey. The TypeBasedPointsToCallGraphKey only implements PointsToCallGraphKey, so the incompatible analysis is not loaded. I made all other direct children of PointsToCallGraphKey inherit from AllocationSiteBasedPointsToCallGraphKey instead, so they all still load the desired analysis.

[errt]

Looks good to me.

I wonder whether we should rename the ReflectionAllocationsAnalysisScheduler to be compatible with getModuleFQN though.

[johannesduesing]

I think that's fair, i can implement that. However i'm just now wondering: The CFA_1_0_CallGraphKey also has pointsToType = "TypeBased" - should it be using the ReflectionAllocationAnalysisScheduler at all, or are they also incompatible?

[errt]

None of the type-based points-to analyses (including 1-0-CFA) can use the allocation information. Though we could check whether it is useful to extend the analysis to provide type-based points-to sets for these.

[johannesduesing]

Maybe we need two analyses then, with the correct one being loaded via getModuleFQN .... I'll have a look into that!

[errt]

Our points-to analyses are flexible enough to handle such cases with one analysis (and two schedulers), but I'm not sure whether such an analysis is any useful for type-based points-to analysis or not.