…sses

PythonWrapperGenerator now uses PythonBytecodeToJavaBytecodeTranslator's
ClassLoader, which allows PythonClassTranslator to extend
Planning Entities and Problem Facts.

Because JPype automatically maps Java fields to Python fields, the
generated field and method names were changed to illegal identifiers
in Python (but legal in Java). This is becausing having the
fields/methods "hides" the Python Object fields
(which are accessed via __getattr__, which is only called if the field
is undefined), thus passing a PythonLikeObject to CPython, which
can cause type confusion when the user access it.

Has parent checks need to be changed, since every planning entity,
problem fact and planning solution now extend a class
(the translated Python class). For fields and method, the check
basically changed to trying to get the field/method from the
parent class, and creating the field/method if it does not
exist.

Added a new constructor <init>(PythonLikeType) to
entities/problem facts/planning solutions, which allow
PythonClassTranslator to extend them. Because the
extended class will NOT have the old expected constructor
(only a no-args and one that takes a PythonLikeType), added
a new "init" method for domain objects that serves the
old expected constructor purpose.

On construction, we set all the parent object fields from
the CPython Object. Additionally, we call both the OptaPy
and translated setter when setting domain fields.

Because class translation will happen for all domain object,
class translation will create a proxy to the CPython version
if it was unable to translate the method for any reason.

Bug fixes:

- Update getPythonLikeObjectForAttribute so that it unwraps
  OptaPyObjectReference instead of Long

- extract_joiners did not unpack the type tuple, thus sending a
  tuple containing a tuple containing the stream types to the
  translation, causing the code to not be translated.

- Added missing compareTo method for PythonString