Symlinks for nightly tarballs, Windows builds via Appveyor CI platform

First things first: Thanks Frediano (et al) for your hard work! Here's
hoping 0.95 is a great release.

I've found the files published under ftp://ftp.freetds.org/pub/freetds/ and
their symlinks suffer from some issues:

a. In current/ subdir: Newest snapshot as of now is
freetds-dev.0.92.1014.tar.gz created on Apr 9 2015 which seems to be
correct as the last commit to master branch is around such date but the
freetds-current.tgz tarball actually poins to freetds-dev.0.92.990 from
March 24.

b. (nitpick) no freetds-current.tar.bz2 symlink is published.

Found this while I was trying to set up automated builds of FreeTDS on
Windows using hosted CI services provided by AppVeyor (appveyor.com, free
for Open source projects). See [1] for an overview, [2] for the console
output of one of the four build jobs I created and [3] for the
corresponding artifacts.

I've settled for now on creating a fork of the of [4]Branch-0_91 Git branch
(0.91 plus stable fixes backported through the 2008-2014 period) in which
./configure has been [5]run on a Linux system to get some generated needed
files created, performing some [6]code tweaks so MS Visual Studio can
digest it, and compiling x86/x84 Visual Studio 2008/2010 versions by
[7]crafting and adding the needed appveyor CI configuration.

This is part of an effort to streamline testing and generation of releases
for the FreeTDS-based [8]pymssql Python driver for SQL Server/TDS of which
the official Windows binaries include FreeTDs linked in statically.

No attempt has been made yet to run the test suite (SQL Server versions for
2008 onwards are
available on Appveyor to run the tests against). I actually don't know if
the suite works on Windows or if it contains "unixisms" that would make
this impossible.

Also, still haven't tried to build FreeTDS pre 0.95 (from the master
branch). Hopefully will be able to do this soon, before the actual release
happens.

Maybe these appveyor CI config files can be incorporated into the FreeTDS
tree at some point, once they are more mature.

Something similar can be implemented for Linux CI builds using services of
other similar companies like TravisCI/CircleCI, but in these cases test
suite execution would need to be pointed to a SQL Server instance hosted
somewhere else just like Marc Abramowitz implemented for pymssql some time
ago.

This is one of the advantages of being on GuitGub: Integratiion with that
kind of third party services is trivial.

Regards,

1. https://ci.appveyor.com/project/ramiro/freetds
2. https://ci.appveyor.com/project/ramiro/freetds/build/job/8ynnnuc17qe7m7f6
3.
https://ci.appveyor.com/project/ramiro/freetds/build/job/8ynnnuc17qe7m7f6/artifacts
4. https://github.com/ramiro/freetds/tree/appveyor-0.91
5.
https://github.com/ramiro/freetds/commit/ce181c3c8aa01a7e1ab489bc141a51aa18d11af9
6.
https://github.com/ramiro/freetds/commit/6365d00188acf736c4e50db151461738c1d418f6
7.
https://github.com/ramiro/freetds/commit/aa1038db5f882f80d6e7f4d483942f7b508a1d61
8. http://pymsssql.org

-- 
Ramiro Morales
@ramiromorales