don't need FDSET_LONGS

[Jeff Johnson]

a devchk complaint is native headers don't define FDSET_LONGS. We probably
captured this from an upstream version but there's no particular need for the
constant.

> ... __FDSET_LONGS is defined in linux/posix_types.h.

again, this makes me question whether we're actually doing the right thing.

POSIX says, and glibc implements, defining the important values in
<sys/select.h>, not in <sys/types.h>:

   The <sys/select.h> header shall define the following symbolic constant,
   which shall have a value suitable for use in #if preprocessing
   directives:

   FD_SETSIZE Maximum number of file descriptors in an fd_set structure.

   The following shall be declared as functions, defined as macros, or
   both. If functions are declared, function prototypes shall be provided.

   void FD_CLR(int, fd_set *);
   int FD_ISSET(int, fd_set *);
   void FD_SET(int, fd_set *);
   void FD_ZERO(fd_set *);

there's no mention here of FDSET_LONGS...

we have:

    typedef struct {
        unsigned long int fds_bits[__FDSET_LONGS];
    } fd_set;

and could just as easily have:

    typedef struct {
        unsigned long int fds_bits[FD_SETSIZE/NFDBITS];
    } fd_set;

since it turns out that's pretty much the way it gets defined most places.

There's an entirely different question, which is why LSB defines this in
<sys/types.h>. POSIX describes it as <sys/select.h>, and this is also where
glibc places the defines. I have some vague memory we had include problems,
but we have a better ability to link files together now if this turned out to
be a problem.