uucore/entries: fix getgrouplist wrapper to handle a bug in macOS's getgrouplist implementation

[jhscheer]

While testing my PR for id (#2361) I noticed that (although coreutils Testsuite passes for id) my tests on macOS return less groups than both GNU's coreutils id and Darwin's id:

run: gid runner
run: /Users/runner/work/coreutils/coreutils/target/x86_64-apple-darwin/debug/coreutils id runner
thread 'test_id::test_id_single_user' panicked at 'assertion failed: `(left == right)`

Diff < left / right > :
-"uid=501(runner) gid=20(staff) groups=20(staff),0(wheel),12(everyone),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin)\n"
+"uid=501(runner) gid=20(staff) groups=20(staff),0(wheel),12(everyone),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),264(_webdeveloper),399(com.apple.access_ssh),701(com.apple.sharepoint.group.1),33(_appstore),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing),400(com.apple.access_remote_ae)\n"

The first thing I saw is that in uucore::entries the return value of the second call to getgrouplist wasn't handled and on macOS it is always -1. Then I did some digging and learned that this is a bug in Darwin's implementation of getgrouplist where getgrouplist doesn't update ngroups if ngroups is too small.
First i thought the solution would be to query libc::sysconf and then just use the run time value of _SC_NGROUPS_MAX for ngroups. However, that turned out to be always 16, although the real ngroups could be much higher.
So the only solution is to call getgrouplist repeatedly and to manually increase ngroups if not done so automatically by getgrouplist.

Note1: I checked and this solution is also done by gnulib
Note2: it's not enough to solely rely on the results from coreutils 8.32 Testsuite