combining XuInteger and IntegerVar

[Eric Dean Tribble <tribble>]

Caveat:  We will not do this before Alpha.

Abstract: MarkM and I figured out how to make pointers to XuIntegers
operate as efficiently as IntegerVars do now.  These would replace
IntegerVars, and simplify much of the code that currently must
amnually do boxing and unboxing.  It would also simplify the
documentation task, I think.

We've talked about this before but were stumped by a few problems that
have gone away:

The two enabling insights: 

1) Coercing an IntegerPointer to a HeaperPointer boxes the Integer.
This lets us avoid the Smalltalk problem of having to check a bit on
every pointer operation to make sure that the pointer is actually a
pointer and not an optimized Integer.  We'd go ahead an add the bit
test to all Position operations, however, so all the region and table
key operations are efficient for Integers.
2) We already pay the bit testing overhead for all IntegerVars because
they get boxed if they go into BigNum range, so we wouldn't be doing
any more work with this scheme.

To a first approximation, sending any message to an Integer boxes it.
We'd probably have to improve on this a little bit (isKindOf for
instance), but this guarantees the semantics appropriately.

The various math operators would be defined for the IntegePointer type
and would semantically correspond to particular message sends (a + b
<=> a->plus(b)).

For cases that needed it, we could have a second type of HeaperPointer
that did all the bit testing so that it didn't need to box optimized
Integers.  We might use this as the return type from Stepper>fetch for
instance, if we find much of our time going to wandering around
regions.

I'm inspired to think about this because I spend so much time
wandering between XuIntegers and IntegerVars, and looking at the code
that gets crufted up by worrying about the difference (imagine all
those .IntegerVar overloadings vanishing!).  It think we should
consider this soon after Alpha.

dean