Move the Unix configure script up to the top level.

Previously, 'configure' and its assorted machinery lived in the 'unix'
subdir, because that seemed like a clean place to keep it given that
all the other per-platform Makefiles live in their platform
directories. However, this never sat all that happily with autotools,
and even less so now that it likes to have object file pathnames
parallel source file pathnames: if you have Makefile.am refer to
source files outside its subdir as "../terminal.c" and enable
subdir-objects then any out-of-tree build calls the corresponding
object file "../terminal.o" and so your build products mostly end up
at the directory above your build dir! And as of autotools 1.14 my
previous compensatory bodge of prefixing every source file path in
Makefile.am with "$(srcdir)" has stopped working too.

So I'm giving in to necessity, and changing policy by moving the
configure machinery up to the top level of the source tree where
autotools will be less confused by it. This should not be taken as any
indication of the primacy of the Unix port, only of the recalcitrance
of autotools.

Whereas before we had a trivial script called 'configure' at the top
level that invoked unix/configure to effectively do an 'out-of-tree
build' (for make purposes) at the top level of the source tree, we now
have a similar script in unix/configure. So this _should_ make very
little difference: people who were previously running configure from
the top level should still be able to, and likewise people who were
running it from the unix subdir.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10141 cda61777-01e9-0310-a592-d414129be87e
Add the 'subdir-objects' option in the automake makefile.

This rearranges the object files so that they each live alongside
their original source file, instead of all being in the same
directory. To my way of thinking this is a more or less neutral change
(perhaps marginally less tidy), but autotools is apparently beginning
to think it's the One True Way and 1.14 will give a warning if you
don't have it enabled.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10142 cda61777-01e9-0310-a592-d414129be87e
Add the autogenerated empty.h to CLEANFILES.

Colin Watson points out that it's untidy to create it with the
makefile but not clean it up again in the same way.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10143 cda61777-01e9-0310-a592-d414129be87e
Add some assertions in sshzlib.c.

gcc 4.8 compiling with -O3 gives a new warning about the access to
st->pending at the top of lz77_compress, because for some reason it
thinks there's an out-of-bounds array access there (or perhaps just a
potential one, I'm not really sure which side -Warray-bounds is erring
on). Add an assertion reassuring it that st->npending can't get bigger
than the size of st->pending at the site it's complaining about, and a
second one at the site where st->npending is increased (just in case
my analysis of why it can't happen was wrong!). Also add a comment
explaining the assertions.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10144 cda61777-01e9-0310-a592-d414129be87e
Add a missing bn_restore_invariant in RSA blinding code.

We were inventing a random number by starting with a long zero bignum
and then setting bits at random, which left an opportunity for the
result to be a non-normalised representation (with a leading zero
word) and hence fail an assertion in bignum_cmp.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10147 cda61777-01e9-0310-a592-d414129be87e
Have mksrcarc.sh log its activity to standard output.

Its previous policy of silence made sense before we did builds using
bob (gratuitous output on success caused cronmail) but now it just
makes it hard to spot problems.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10153 cda61777-01e9-0310-a592-d414129be87e
Add 'set -e' to mksrcarc.sh, so it spots zip returning error.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10154 cda61777-01e9-0310-a592-d414129be87e
Stop using 'zip -k' to construct the Windows source archive.

It was intended to ensure that people still working with DOS filename
restrictions (or things approximating that, e.g. VFAT) wouldn't have
trouble. Those days are surely long gone, and now zip -k is causing
its own trouble with the new VS2010/VS2012 project files, which
include pairs of filenames that become the same under the zip -k
transformation and hence break the source archive build.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10155 cda61777-01e9-0310-a592-d414129be87e
New FAQ, aimed at the people who periodically send us large
questionnaires in unfriendly formats like Excel, apparently in the
mistaken belief that we have some kind of incentive to answer them. I
hope I've managed to identify the key reason why they make this
mistake.


git-svn-id: svn://svn.tartarus.org/sgt/putty@10156 cda61777-01e9-0310-a592-d414129be87e