getgrouplist module is now higher priority

[Jim Meyering]

Theodoros V. Kalamatianos discovered that getgrent mistakenly
sets errno=ENOENT on EOF when /etc/nsswitch.conf specifies e.g.,

    group: nisplus

This causes some new getgrent failure-detection code to report a
false positive for the bogus ENOENT.
[getgrent returns NULL both to indicate EOF and to indicate an error.
 Setting errno=0 beforehand and checking it afterwards is the only
 way to distinguish failure and EOF. ]

This came up because a program used in coreutils testing framework
would fail for root-only tests (not a big deal):

  # ./setuidgid +0 true > /dev/null
  ./setuidgid: failed to get groups for user `root': No such file or directory

But you can demonstrate the same effect with "id" from the
just release coreutils-6.10:

  $ ./id root
  uid=0(root) gid=0./id: failed to get groups for user `root': No such file or 
directory

As such, and considering the POSIX recommendation to avoid getgrent, I'll
soon finally switch to using get getgrouplist, per this TODO file entry:

  Implement Ulrich Drepper's suggestion to use getgrouplist rather than
    getugroups.  This affects both `id' and `setuidgid', but makes a big
    difference on systems with many users and/or groups, and makes id usable
    once again on systems where access restrictions make getugroups fail.
    But first we'll need a run-test (either in an autoconf macro or at
    run time) to avoid the segfault bug in libc-2.3.2's getgrouplist.
    In that case, we'd revert to using a new (to-be-written) getgrouplist
    module that does most of what `id' already does.  Or just avoid the
    buggy use of getgrouplist by never passing it a buffer of length zero.
    See http://bugzilla.redhat.com/200327

Now that there are two clients, we definitely need a getgrouplist
module for gnulib.  If someone writes it in the next few days,
that'd be great.  Otherwise, I'll get to it.