Installer, README, and ID clarification

The most important part of this is the installer, which is a fix for issue #2.  It's a fairly boring update of the .nsi script in distrib/.  All that's required now is to install NSIS, and then after building AviSynth+, right-click on distrib/AviSynth+.nsi and select 'Compile NSIS Script'.

I've provided an installer-based build for testing (hopefully MediaFire han't disabled it):
EDIT: new one:
http://www.mediafire.com/download/4ope3hcdppfahza/AviSynth%2B_131105.exe

<b>Differences from the original:</b>
A) The installation directory is set to 'AviSynth+' by default, not 'AviSynth 2.5'.  If the user is only going to rely on avsplus, it doesn't make sense to continue putting it in '2.5'.
B) It does create and register both PluginDir2_5 and PluginDir+ directories.  The included plugins get installed to PluginDir2_5.
C) It disables the ability to install .map files, since they aren't generated during the compile process anymore. Supposedly, this is done by using Visual Studio's /MAP flag. That stuff was merely commented out, so if .map file generation is re-added, it can just be uncommented.
D) It disables the installation of TCPDeliver.dll and VFAPIFilter.dll, for the obvious reasons. Like with point C, they're only commented out, for whenever they <i>do</i> get enabled again.
E) The doc stuff is now installed in a 1:1 equivalence with how it exists in the source tree.  It's not Docs/[language]/index.html, it's docs/source/[language]/index.html.
F) The VC6 stuff has been removed.  This means the user will need to know which runtime to install, or there should be some sort of detection to grab the runtime .dll that corresponds with whichever version of VS it was built by and include it in the installer.
G) The include/ directory is still installed to FilterSDK, but it now has the avs/ subdirectory in it too.

I tested the install and uninstall under Wine on an OSX Guest account so that I could be sure it was clean and didn't have to worry about screwing things up.  It probably needs some testing under real Windows to be certain.

<b>TO-DO:</b>
I'm not sure how to handle packaging both 32-bit and 64-bit versions into a single installer, which would be very helpful for whenever 64-bit matures.  I guess we'll just have to cross that bridge when we get there.

Move more of the references in the Installer's language over to 'AviSynth+', and do the same for the documentation.

<b>Wishlist:</b>
Find some way to allow AviSynth+ and classic AviSynth to co-exist without conflicting.  IMO, it would be more ideal for avsplus' AviSynth.dll to reside in its main directory in Program Files and be registered to the system out from there (mainly because I hate having to go spelunking in system32).  There would need to be a priority system in place so that avsplus would be preferred over classic since the assumption should be that if the user installs avsplus, they want to use its features more than those of the original.

To go along with this, it'd be pretty cool to have a hashbang-esque invocation style (or something more AviSynth-y that acts as an analogue, like SetCoreLibrary() or whatever) that allows the user to override this priority and use the installed AviSynth version of their choice (so long as the names are unique).  If this happens, then avsplus would act more like a middleman and hand the rest of the script over to the other interpreter, or it would act to turn off the avsplus-specific extensions.



The README is just a basic re-rendering of the Doom9 announcement post in reST format (at least it's a start), and the ID stuff is partially so that the .dll can be distinguished easily, and because it needs to be obvious to the end user that they're using avsplus rather than classic.