Enhance hash key computation and usage

[thomaskeller79]

Perfect hash keys are important for the efficiency of the planner, but their implementation is outdated. In this issue, we'd like to look into possibilities to enhance their usage:

• currently, perfect hash keys of states and KleeneStates are longs. We should use unsigned long longs instead which can be used with at least 63 variables (for (signed) longs, the guarantee is only 30 variables)
• usage of state hash keys is currently a black or white decision: it is either possible to compute perfect state hash keys or it isn't. However, it might make sense to use a (good) hashing function and also enable the usage of imperfect hash keys

This is an important question as the instances we consider get larger and larger, and it becomes less and less likely that we can cache the information we have computed once.

[thomaskeller79]

It would also be nice to hide the hash keys better from the user, but I am not sure this is the right issue to approach this - this issue is mostly (but not only) a parser issue, whereas the usage is mostly a search issue

[thomaskeller79]

Once we have merged issue #102, we should also evaluate if it pays off to treat action fluents different from state fluents. I assume that we do not gain much from the special treatment anymore, but the code would be much simpler if we treated all fluents identically.