Remove exe builds

[phihag]

Currently, the exe files in our repository are blowing up the repository size significantly. Additionally, as it stands, @FiloSottile is probably the only one with the precise configuration to build them.

We should banish the exe and associated scripts into a secondary repository, managed by someone who is vell-versed with the intricacies of Windows builds.

[FiloSottile]

We surely need to move all the built binaries out of the versioning
system. Allowing for nightly builds and simple merges.

Also, you are probably too kind to mention it, but me being the only
exe builder is a quite serious security/backdooring threat, I know
this.

I failed hard at trying to get wine-py2exe working on Debian (even if
I can remember someone managing to get it working on some Ubuntu) but
please note that it is only a drop-in replacement for a real
Windows+py2exe environment. So, the build is really easily doable on
any Win machine, and actually, the latest one has been made on a Win
EC2 (0.10 euros) as I didn't have my PC at hand.

After all, considering how useful this build seems to be (I get a
number of emails from people using it, and I think a video conversion
program integrated it) maybe we should take it out of the repo, along
with all the compiled files, and try to automate a small EC2 builder.

[fraca7]

I have a WinXP Pro SP3 VM that is currently almost exclusively used as a buildslave for Task Coach (http://www.taskcoach.org/); it has Python 2.7, py2exe, win32all, GNU Make and other stuff already installed. I can contribute by setting up a buildbot for youtube-dl if you're interested.

[gcmalloc]

I think this issue can be merge with issue #423. There is a whole section in github specially design for uploading binary file. In youtube-dl, that would correspond to https://github.com/rg3/youtube-dl/download.

We could go to build automation by the following means.
First clean the repository from the windows builder. That means moving the py2exe shell script into their own depot. We can still keeping a submodule referencing the depot. The setup.py script can also be cleaned at this phase (referring to #412, #460). With custom build rules including the one actually in the Makefile. That would make a single script more maintainable.
Then provide proper testing before the building, and befor merge request. That is motivated by two reason. First, we don't build anything that doesn't provide at least a minimal set of requirement. Secondly, we could merge pull request more easily.
Then, last but not least, setup build bot for platforms.

[FiloSottile]

I've setup a public editable wiki page in my fork. I suggest consolidating there all the intentions for the new build system.

Be bold: don't wait for approval, at least in this early stage, and write directly there (it's all versioned after all).

https://github.com/FiloSottile/youtube-dl/wiki/New-building-system-blueprint

[gcmalloc]

That's just perfect, thanks for your motivation.

[FiloSottile]

And eventually we are done (almost, but it's ok)!