expairseq::match(): no side effects if match failed. Fixes spurious match failures.

> match(sin(y)*exp(b)+sin(x)*exp(a), sin($0)*exp(a)+exp(b)*sin($1))
FAIL

The reason is that expairseq::match() might assign a wildcard even if
the match fails. The first attempted submatch is sin(y)*exp(b) with
sin($0)*exp(a). It fails (as it should) but $0 == y gets assigned as
a side effect (which is wrong). Next submatch is sin(x)*exp(a) with
sin($0)*exp(a) (the same pattern as in the first submatch). This one
fails because of spurious $0 == y assignment.

Due to the unpredicatable term ordering the sequence of submatches might
be different and the match might succeed (as it should). This makes
debugging a bit more funny.

Signed-off-by: Matthias Dellweg <dellweg@tp1.uni-duesseldorf.de>

[Alexei Sheplyakov: figure out the cause of the problem, make a test case]
Fix evaluation of log(p^a) -> a*log(p), if p>0 and a is real.

This evaluation was broken with commit e5c76f659e2e882d.
Avoid calling log(1-x) for x=1 in Li_projection.
Within mLi_numeric, set signs of the imaginary parts correctly for G_numeric.
Fix G3_evalf and G3_eval for real and negative x.

The user supplied signs of the imaginary parts are only relevant for x real
and positive. A negative sign in the case of x real and negative is irrelevant
(there is no branch cut) and led to wrong results. This is now avoided.
Fix S_num for arguments close to the sixth root of unity or its conjugate.

The method S_num within the Nielsen polylogs used to map the region
abs(x)<=1 && abs(x)>0.95 && abs(1-x)<=1 && abs(1-x)>0.95 infinitely many times
onto itself. This infinite recursion is now avoided.

This however reveals the next problem: The numerical convergence in this
region is very slow. Within the Nielsen polylogs there is no transformation
available to improve the convergence. However we can use the (1-x)/(1+x)
transformation within the harmonic polylogs. In order to avoid another
infinite recursion I have inserted a few hold()'s in the method H_evalf,
otherwise we would fall back immediately again to Nielsen polylogs. The hold()s
should have been there anyway.
Li_eval(): avoid the "numeric::operator>(): complex inequality" exception.

Basically the problem is that 1 + 0.0*I is equal to 1, but checking if
the former is positive results in the the "numeric::operator>(): complex
inequality" exception. This behavior is definitely inconsistent and should
be fixed.

As a work around teach Li_eval and convert_parameter_Li_to_H to explicitly
convert 1 + 0.0*I to 1 (and -1 + 0.0*I to -1, respectively).

[Alexei Sheplyakov: comment the code a little bit, otherwise it looks weird]
log_eval: don't apply the log(x^p) -> p*log(x) rule.

Automatically transforming log(p^2) into 2 log(p) might be quite annoying.
Perhaps this transformation should be moved to expand() and applied only
if expand_options::expand_transcendental is specified.
[build] ginsh: fix `make distcheck' failure.
check: auto* tools build: compile and run check_mul_info.
[build] Include the helper scripts into the tarball.
[build] Include CMake related files into the tarball.
[build] Include the generated sources (function.{h,cpp}) into the tarball.
[build] Fix `make pdf' for out of the source (auto* tools) build.
[build] Document that Python is required for building GiNaC.
Binary compatibilty has been broken, update the library version.

commit 798d53ebb4da4e8e3865ed7bd7f31412fe2be3a7 (`Make it possible to override
info() for functions.') overrides the function::info() virtual method. This
breaks binary compatibility (adds a new entry in the middle of the vtable of
the `function' class).

The experimental proof of the above statement: ginsh linked with the previous
release of libginac segfaults if libginac.so is upgraded to the current
version.

Thereore bump the library version.
[docs] remind users tho send EOF marker when doing input from cin.

The example program waiting infinitely for EOF has confused at least one
user: <http://www.ginac.de/pipermail/ginac-list/2014-January/001983.html>
G_numeric: fix numeric evaluation with trailing zeros and y != 1.

Make sure G_numeric makes use of scaling relation (G_do_hoelder) only if
there are no traling zeros. Use G_do_trafo otherwise (which can handle
trailing zeros).
G_do_hoelder: fix the transformation of the imaginary part.

The G_do_hoelder function transforms the arguments as z -> 1-z.
If z has an imaginary part, the sign of the imagniary part transforms
as s -> -s.
In the special case where z is real and > 1, the transformed value is
real and < 0. For (transformed) real negative values of z the sign of
the imaginary part is not relevant (there are no branch cuts). The code
requires that in this case the sign takes the default value +1.
This is now fixed.
Fix an infinite loop in factor_multivariate.

Make sure the leading coefficient is really factorized (take care of
the integer content).