library: slab is redesigned to use 'stack' vs. 'chain'

library: slab is redesigned to use 'stack' vs. 'chain'

In addition to that text shown below the line which is
common to several commit messages, this patch contains
several minor changes with lessor impact upon the API:

. A 'read' was added to function procps_slabnode_count
(but only when necessary, i.e. info->nodes_used == 0).

. The #include header files are ordered alphabetically
now, with all those <sys/??> types separately grouped.

------------------------------------------------------
. The former 'chains' have now become 'stacks' without
the 'next' pointer in each result struct. The pointers
initially seemed to offer some flexibility with memory
allocations and benefits for the library access logic.
However, user access was always via displacement and a
a statically allocated chain was cumbersome to define.

. An enumerator ending in '_noop' will no longer serve
as a fencepost delimiter. Rather, it has become a much
more important and flexible user oriented tool. Adding
one or more such 'items' in any items list passed into
the library becomes the means of extending the 'stack'
to also include user (not just library) data. Any such
data is guaranteed to never be altered by the library.

. Anticipating PID support, where many different types
must be represented in a result structure, we'll adopt
a common naming standard. And, while not every results
structure currently needs to reflect disparate types a
union will be employed so the same dot qualifier ('.')
can be used consistently when accessing all such data.

Signed-off-by: Jim Warner <james.warner@comcast.net>