* it was necessary to increase the upstream version so I could
   upload new versions to launchpad while debugging PPA build issues.
 * ChangeLog finalized for v0.6.4
 * SciTECO requires at least libglib v2.28 (but that's only a guess)

 * it also sets the compatibility level to 7 which was required
   when building for Ubuntu Lucid. This version cannot be supported
   however since its libglib version is too old.

 * you no longer have to make an entire clean when e.g. uploading
   for another Ubuntu release. Therefore, the source tar ball is
   preserved (it must be the same for all packages with the same
   upstream version).
 * also try to extract the SciTECO version from the ./configure script
   instead of hardcoding it in ./distribute

 * v4.4 is still officially supported by SciTECO (see INSTALL)
 * Ubuntu Lucid appears to use v4.4 by default and lucid is till
   supported by PPA. So this should fix building SciTECO in its PPA
   for Ubuntu Lucid.

 * If TERM is set but wrong, it might still fail. Errors are reported now.
 * If $TERM is unset or empty, we refuse to start the interactive mode.
   Unfortunately, we cannot easily let curses decide this since
   newterm() does not work as expected.
 * However this solution should be quite good: Either $TERM is empty - then
   batch mode will work but not interactive mode.
   Or it is not empty, then it is checked by the first call to newterm()
   when initializing batch mode.
   The chance of starting up interactive mode with a wrong $TERM
   or in head-less environments is now quite low.
 * This is most likely responsible for the PPA build issues.

this was probably a regression from d94b18819ad4ee3237c46ad43a962d0121f0c3fe
and should not be in v0.5.
The return value of Expressions::find_op() must always be checked since
it might not find the operator, returning 0 (it used to be 0).
A zero index pointed to uninitialized memory - in the worst case it
pointed to invalid memory resulting in segfaults.
Too large indices were also not handled.
This was probably responsible for recent PPA build issues.
Valgrind/memcheck reports this error but I misread it as a bogus warning.

I took the opportunity to clean up the ValueStack implementation and
made it more robust by adding a few assertions.
ValueStacks now grow from large to small addresses (like stack data
structures usually do).
This means, there is no need to work with negative indices into the
stack pointer.
To reduce the potential for invalid stack accesses, stack indices are
now unsigned and have origin 0. Previously, all indices < 1 were
faulty but weren't checked.
Also, I added some minor optimizations.