Position asRegion

[Eric Dean Tribble <tribble>]

Position have two semantically poor messages in their protocol:
asRegion() and table(size).  I think the correct implementation will
need a coordinateSpace to determine the type of region or table to
create.  Also the mesages don't follow our use of pseudo-constructors
for type conversion (which we never been documented...).  The asRegion
message should either be a Region pseudo-constructor with a Position
and a CoordinateSpace, or a message to a coordinateSpace with a
Position.  I think I like the former.  The table message should
likewise be a Table pseudo-constructor.

I ran into this while implementing some selection stuff.  To compute
the selection range based on two position, I just turn them both into
regions and get the simpleUnion.  This does the right thing for linear
selection in text, tree selections in the inclusion list (assuming the
appropriate treeSpace), and for 2d (I think).  'asRegion' doesn't work
for treeSpaces right now, though.  By choosing among the different
tree coordinateSystems, we can define what treeRegions look like
(subtrees vs. ranges of sibling subtrees vs arbitrary ordering) and
get different selection and edinting behavior.

Ravi, Hugh: do treeRegions exist?  Are these changes consistent with
the new Regions?

dean