[Swan] lset_t usage is a mess in Pluto

[D. Hugh Redelmeier]

lset_t was designed to be a way of representing set of elements of a 
modest enumerated type.  They are represented as bits in some unsigned 
type.

Originally, the limit on the value of an element was 32 so that lset_t 
could be represented as unsigned long (guaranteed by the C standard to 
hold at least 32 bts).

Someone after me found that they needed more than 32 elements for some 
member type.  So they redefined lset_t to be unsigned long long.

This was a bit brute force: every lset_t became twice as large and, on 
many machines, the operations upon it took twice as many machine 
instructions and register.  I guess that everything is cheap these days, 
so it is kind of OK.

Whoever wrote xauth.c seems to have decided to use unsigned int for the 
representation of some sets, but still use the lset_t operators.  And 
didn't document it (actually, there is a tiny bit of documentation that is 
wrong).

When I created lset_t, one size was enough.  Do we really need all these 
different sizes?  If so, we really ought to have different set types for 
each size (set_t, lset_t, llset_t would mimic C's unsigned types)?  If C 
were more powerful, a set type for each enum would be even cleaner (like 
Pascal).

xauth.c is a bit of a mess anyway.  I'll switch the unsigned int to 
lset_t.