top: provide an unlimited capacity for field additions

top: provide an unlimited capacity for field additions

With each of those references shown below, the maximum
number of fields was increased. However, with a 'char'
based implementation we're nearing the upper limits of
total displayable fields. We currently use 76 of a max
of 86 fields. With extra effort, 94 might be possible.

But 94 is the absolute upper limit of possible fields!

Moreover, the current implementation yields characters
that were unprintable in the rcfile. This could become
an issue with that 'inspect' feature when/if an rcfile
is edited to add entries (as opposed to using 'echo').

So, with this commit the internals of field management
has been completely reimagined. It is now based on the
integer type, not a character. And whereas that former
design used the high order bit to show the 'on' state,
thus yielding an unprintable character, the new design
uses the low order bit for the state. As such, numbers
will be kept small and an even number will be an 'off'
field whereas an odd number will become an 'on' state.

The bottom line is that this new design will afford an
unlimited number of new fields while keeping an rcfile
completely free of that potential unprintable garbage.

And it is embarrassingly easy to extend the maximum of
supportable fields from the currently implemented 100.
Who knows, maybe a future patch will prove this point.

[ unless a subsequent commit proves otherwise, given ]
[ the dramatic differences in rcfile contents, i had ]
[ to abandon the practice of supporting old rcfiles. ]

Reference(s):
. Nov, 2013 - RCF_PLUS_H introduced
commit af4e6533ba5ee04f414bc8774df31ddef38e8880
. Jul, 2016 - RCF_PLUS_J introduced
commit d5c5051fb395e8bebaadb42add79ca99a16afe85

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