Updated Hierarchy to Java 5

Problem: Client code should not have to guess what is contained in the List
returned by the Hierarchy.

Changes:
 * Added generics to the return types of List that were missing.
Updated MultiMap and HashMultiMap to Java 5

Problem: Clients should not have to guess what objects a MultiMap will return.

Changes:
 * Added generic types to MultiMap and HashMultiMap
 * Clarified return types and parameter types
Made FastHierarchy.getAllSubinterfaces public

Problem: Clients may need to know what are the subinterfaces of an interface

Changes:
* Updated MultiMap to use generics
* Made getAllSubinterfaces public
* Added a non-interface check in getAllSubInterfaces
* Transformed some loops to for-each loops
Fix for #118

Added a boundary check to determine the propagateDef flag
Merge pull request #119 from malaverdiere/develop2

Fix for #118
Merge pull request #117 from malaverdiere/develop

Misc Updates to Hierarchies
removed commented-out code
Added a trap splitter to handle overlapping / nested try/catch blocks. They are not supported in Dalvik, but can exist in Java. If we try to inject a Java class into Dalvik code, we need to split them so that we get distinct flat try/catch blocks.

Assume: start1 .. start2 ... end2 ... end1. We tranform it to start1 ... end1, start(1,2) ... end(1,2), start1 ... end1 where the (1,2) block in the middle contains the merged handlers for the different exception types handled by 1 and 2.

This is to fix issue https://github.com/Sable/soot/issues/116
Merge branch 'develop' of github.com:Sable/soot into develop
added a missing class
Merge remote-tracking branch 'upstream/develop' into develop
Support for reading and writing Dalvik Annotations
#1: added type information
#2: made an error message more informative
Fix for #120

Problem:
When a jar file contains both .class and .java files, the .java files
are picked up and given to the class loading algorithm to read. However,
the Java front-end cannot read from an archive and throws an exception.

The exception states that Polyglot isn't able to load the file, but
this can be confusing when the user is running Soot with Polyglot disabled.

Solution:
Ignore .java files in archives

Changes:
 * Ignored .java files in archives in SourceLocator
 * Improved the exception message in JavaClassProvider
Merge pull request #121 from malaverdiere/develop

Fix for #120
Merge remote-tracking branch 'upstream/develop' into develop
bug fix: also check field assignments when resolving numerical types
Get correct base type for multi array. Method getBaseType() in NewArrayExpr and NewMultiArrayExpr classes should be renamed/deprecated since they are confusing.
By default Soot keeps the raw string for annotation type representation. Do the same when reading/writing Dalvik annotation tag types.
Merge remote-tracking branch 'upstream/develop' into develop