sys-libs/ncurses: various cleanups/sync-with-upstream

Untested because as of now, fails to build due to rebasing errors.
(Back I go to libtool hacking...)
a tiny script to run before commits
sys-devel/libtool: more unc path suppression
README: mention that we dont support unc paths
sys-devel/libtool: backport 2.4.2 stuff and sync with upstream a bit
sys-devel/libtool: VICTORY IS MINE!!!

This monster libtool update makes libtool actually work.  Unfortunately
it does so at a pretty high cost:

o ultra-prefixification of libtool
o ultra-prefixification of libtool-generated files which means that
  our overlay is not suitable for generating files intended for
  distribution
o lots of changes relative to our various upstreams, most of which
  cannot go upstream.
o slow, ugly ebuild

However, it works.  Making it "right" is now a matter of fixing
various problems derived from nasty interactions with upstream
packages.  For example, if '//' UNC notation could be deactivated,
we could get rid of all the UNC prevention hacks, or if we could
avoid rebasing problems, all of the ultra-prefixification could
go away (in fact it's worth investigating just how important
ultra-prefixification has turned out to be now that we have
solved various other problems, with an eye towards removal).

The subshell-avoidance stuff, although also ugly, is less horrible
in the sense that even outside of the "gentoo cygwin" context,
and independent of other packaging issues, it addresses a real problem
(cygwin fork() is painfully slow, not to mention prone to causing
rebase issues) which is unlikely to go away.  However much of it still
probably could not go into real libtool insofar as it relies
on bashisms or platform-specific behaviors (a big one -- I don't know
if it's really a platform-specific issue or not -- would be whether
ln -s works if no target exists for the link).  Plus some of it is
just aesthetically ugly, although seemingly "clean code" is not a
design objective that libtool values all to highly to begin with, so
maybe that's OK.

We have upgraded here to libtool-2.4.2, which we have "unmasked"
(figuratively speaking) by uncommenting the KEYWORDS clause.
There is no really good reason behind this decision -- it started as
a whimsical attempt to see how well things ported forward from 2.4-r4,
and after I accidentally blew away much of the 2.4-r4 work, I simply
decided it wasn't worth the effort to try to recreate everything.

If this causes horrible problems, so be it but my guess is this will
be a drop in the bucket compared to the horrible problems we will see
from other causes :).  Another reason I figured this was OK: I'm gambling
that by the time this overlay reaches adolescence, libtool-2.4.2  or
higher will become standard-issue anyhow.

I removed epunt_cxx since upstream did so as well, although this is not
yet reflected in portage_diffs: see bug #410877

Summary of changes:

o ultra-prefixification
o modify install-sh to avoid unneccesary subshells
o remove epunt_cxx
o use libtool-2.4.2
o libltdl: avoid unneccesary subshells
o ebuild: simulate a bootstrap when neccesary to pull changes through
  the autoconf apparati.  This is pretty ugly, but if we use the
  real bootstrap then we have maintainer-mode problems, so picked
  the lesser of two evils imo.

All tests pass!
sys-libs/ncurses: Monster 5.9 update

After lots of head scratching I eventually just gave up on 5.7 ncurses.
Figuring out what broke simply wasn't worth the effort given that my plan
was to immediately abandon it for 5.9-r1 once I got things working again.

o remove the 5.7.xxxx ebuild that we were using before and start fresh with
  the 5.9-r1 ebuild from upstream
o port forward or reimplement most of the changes from the old 5.7 build
o integrate the cygwin and "everybody else" install process as much as possible;
  this version now uses most of the upstream logic for moving libraries
  around after make install; however, I had to make significant changes to the
  upstream logic to make it apply correctly to cygwin
o Exempt cygwin from the "r" LIB_PREFIX in Ada95/configure{,in} just like
  we do for ./configure{,in}
o Somehow, the "r" LIB_PREFIX exception causes a dependency on --disable-memleak.
  That makes absolutely no sense to me, but rather than try to get to the
  bottom of the issue, I opted to just force-enable it like interix does already.
o (use-enable debug memleak) come after the interix/cyg $myconf --disable-memleak
  which means it's not being used.  One wonders if this indicates that
  it's no longer required, but anyhow, it /is/ required in cygwin ATM so I fixed
  it for both of us by moving this from the big econf statement to myconf, and
  applying the use-enable option only if we are on a system other than
  interix or cygwin.  This is definitely something that belongs upstream and is
  worthy of a gentoo bug right now (I'll try to make one soon).
o Patched progs/Makefile.in to avoid a subshell that was causing rebasing errors.
  Interestingly, this subshell cd's to ${ED}bin which is where we happen to have
  the new cygncurses.dll on cygwin -- this is highly suggestive of the possibility
  that $PWD is a frequent factor in rebasing errors in subshells, something
  I hadn't given much thought to until I noticed it.
o More?  Lots of teeny tiny changes went in; most of the changes in overlay were
  actually backports of upstream changes or reversions of changes that we formerly
  had been making here.

So far I've been too 'chicken' to emerge this into my system but it compiles and
installs like a champ, and if I discover that emerging causes some sort of disaster
I'll obviously have to deal with that (I do plan to emerge it soon).

What a challenging ebuild for cygwin!!!  The past week or two of work was basically
all moving towards making this commit work.  I guess I can't be sure all those
changes were needed but I have to say that here in ncurses I'm reasonably happy with
the results.  I still wish it weren't neccesary to make so many changes to
upstream's configure options but ncurses on cygwin is very sensitive in this regard
-- basically we are looking to hit the "sweet spot" that the cygport is using
and almost everything else is kinda broken...  At some point I should return to
this and try to reduce the number of changes but for now this is enough, finally
to start moving forward with other things.