sys-devel/gcc-config: various good things

o try to get some of the cruftiest deltas out of gcc-config-1.4.1
  it's still a pretty horrible mess though.

o in the interest of cleanliness and performance, separate out
  the code that detects whether cygdll_protect is supported by
  portage into a separate routine which caches the result.

  As written, this has a deliberate but awfully subtle
  feature of sorts: it allows a caller to pass the environment
  variable "__portage_supports_cygdll_protect" (it must be set
  to "yes" or "no") in to gcc-config in order to override the
  detection entirely.  My thinking is that this might come in
  handy later if we start incorporating similar detection
  methods into, i.e., eclasses.  But, it really is awfully
  subtle and, except for what you are reading now, undocumented,
  behavior, which perhaps ought to be eliminated by hard-coding
  the variable to "no" at the beginning of the script.

  There are no consumers of this "feature" as of yet and I have
  no immediate plans to build any.

o Stop relying on portageq envvar KERNEL to decide if we are
  running on cygwin -- instead use uname -o.  Neither approach
  is perfect, but suffice it to say that the portageq envvar
  approach was "extremely" imperfect since it would actually
  give the wrong answer in a cross-build, and was also susceptible
  to the KERNEL variable being passed in from the calling
  environment, which is not what we want in this case, because
  we are trying to calculate "REAL_CHOST", not "CHOST" at this
  moment -- in other words, we need to know if this is really
  cygwin we are running on, or not, and that's not what portageq
  tells us the answer to.

o Oopsie!  Now that we have fixed the above bullet point about
  KERNEL detection, the gcc-config in toolchain ebuilds starts
  working.  This revealed a very silly oversight on my part,
  which is that since gcc-config is grabbing the portage
  master_lock as a non-portage process, it always deadlocked
  waiting for its caller to finish when invoked from an ebuild.

  The solution was easy enough -- just lock as a portage process.
  This works great and doesn't break the semantics at all,
  but it does highlight the fact that, really, the portage
  master_lock feature has really shaped up to be a
  cygdll-specific thing, which probably should have "cygdll" in the
  name, and that in fact, what we are calling "as portage" locks
  are really "non-cygdll-update" locks, and what we are calling
  "as non-portage" locks can really only be "as cygdll-update" locks.

  The current naming is so misleading as to have even gotten me to
  use it incorrectly, and I wrote the thing in the first place.  So
  this should really be changed at some point.  But not in this
  commit.

o Add a "-q|--quiet-cygdll-warning" option to gcc-config-1.5 so
  that we can (in a subsequent commit) stop the toolchain eclass
  from dumping this text multiple times during the ebuild
  process, as portage will already do that anyhow.

o when working around cygwin PATH limitations, change from using

   env -i PATH="/bin"

 to

   env -i PATH="${EPREFIX}/bin:${EPREFIX}/usr/bin:/bin"

 To recapitulate (or maybe just capitulate), the extra PATH
 envvar is needed for two reasons: first, and foremost, on
 cygwin we need cygwin-1.dll to be in PATH at all times, or
 else we insta-crash; secondly, cygwin lacks -rpath support,
 which is what we are relying on in upstream Gentoo and other
 elf targets to make env -i foo work (otherwise they would
 always crash with shared library not found errors unless
 we only used it for statically linked executables -- which
 we don't -- even for static executables we need glibc, and
 I would presume -rpath is how that works too).

 So far, I don't think PATH=/bin was causing any trouble, but
 after thinking about it, I've decided that the newer form
 is more correct.  The reason is that PATH="/bin" is relying
 on the "coincidence" (not really, more on that in a second)
 that upstream dlls are named exactly the same as they are
 in upstream cygwin, and, insofar as we are using env -i,
 API-compatible with gentoo prefix DLL's.

 I scare-quote "coincidence" above because in point of fact,
 I've gone to some pains to ensure this is so, for reasons
 just such as this.  There are several problems with this,
 however.  First, API compatibility won't always hold between
 gentoo-prefix and cygwin; in fact it's kind of suprising that
 it's worked as well as it has in this regard.  Second,
 gentoo provides all kinds of frobs that could be used to
 break API compatibility or to require additional .DLL's not
 needed by upstream cygwin.

 Finally, this has also been, I think, to a good extent, a side-
 effect of the fact that I have a reasonably complete
 cygwin install in /; however, not everyone will -- only the
 bare minimum for a bootstrap should be required by prefix to
 be there -- and, in principle, once we have bootstrapped, we
 would ideally like to be able to get rid of even that, leaving
 just the "cygwin" base package installed, and a few core tools
 such as bash which are likely to be hardcoded as /bin/foo in
 too many places to fix.

 By providing a more prefix-friendly path, we circumvent all of
 these problems.  As it turns out, pretty much all the env -i
 usages in upstream Gentoo are more about avoiding other,
 non-PATH environment variables, than avoiding any particular
 executables.  Even if we found usages that /were/ intended to
 scoop up non-prefix executables, unless the executables would be
 missing in the non-prefix cygwin as well, we /still/ would be
 better off using i.e.,:

   env -i PATH=/bin:${EPREFIX}/bin:${EPREFIX}/usr/bin foo

 when possible (the exception would be a script that specifically
 relied on getting file-not-found when executing "foo" as a side
 effect of env -i, but that would be a pretty questionable
 usage anyhow, and one we might want to think about fixing rather
 than going out of our way to support).

Signed-off-by: Gregory M. Turner <gmturner007@ameritech.net>
TODO: rename portage master lock stuff

Signed-off-by: Gregory M. Turner <gmturner007@ameritech.net>