The computation of the hashCode is correct, because it is consistent
with the implementation of equals(). 
The hashCode must be different, when two objects are not equal. 
But the hashcode is allowed to be identical, even if the two objects are
different. For example a variable with name "a" and condition "b" and
another variable with name "b" and condition "a".

The relevant question would be, whether equals() should focus on name
and conditionid. There could be additional entries in the installer.xml
with same name and same conditionid, but different value. This variable
would be different, but because it is conflicting (which one should be
the winning definition?) this case should be avoided. So defining them
as "equal" and rejecting the second one while reading the installer.xml
would be a good solution.
Avoid NPE when conditionid is not set

The conditionid can be null, so we have to handle this case in equals()
and hashCode().

Because there is a Constructor without arguments the name could be also
null. But in all places using this constructor, the name is set
immediatly after creating the instance. So name==null is not relevant.

The Constructor DynamicVariable() should be replaced with
DynamicVariable(String name), because a variable without a name is not
possible. But this could break implementations outside this project.
Comparison of conditionid corrected. THe DynamicVariable is equal, when
the conditionid's either both are null or are equal().

And of course the names have to be equal() also. Null is "not possible"
- see last commit.
Merge pull request #292 from Helpstone/IZPACK-1183

Izpack 1183: Avoid NPE in DynamicVariableImpl.hashCode() and correct implementation of DynamicVariableImpl.equals()