In eager search in ParcPrinter, g and h values can overflow, leading to all
sorts of buggy behaviour, such as endless loops during plan extraction (where
presumably the problem wasn't actually solved properly).

If we don't fix this, we need to at least catch and report this.

This happens, for example, on ParcPrinter #13 (pre file attached) with options
"ou" in r3694 if we disable the LM-cut heuristic's abort on large action costs.

(Should also check other search algorithms and other spots where we use
bitfields for similar kinds of overflow.)