`hierarchy`: orphaned trees

[ragunathjawahar]

One of the assumptions I had while building the hierarchy subcommand feature was that all inheritance hierarchies within an artifact could be traced back to java.lang.Object as the root object. If this assumption were true, then we could construct a single tree that maps all classes packaged into the artifact.

However, this is not right. All artifacts are not self-contained. There could be platform/SDK classes for which we have the references but are not contained in the artifact. For example, android.app.DialogFragment is one. The bundled APK may contain a reference to this class, but eureka cannot access the class file. In this case, it is not possible to traverse its ancestral origin. The same applies to classes referenced from the Java runtime.

Due to this limitation, we end up in situations where users are presented with incomplete and misleading information. We have to mitigate or acknowledge this problem to the users.

Here are some potential first steps,

1. Print debugging information during development to see the number of classes to which we don't have access.
2. Instead of returning a single tree, return all orphaned trees as the parse result and print these roots before starting the server.