Improving the polymorphic dispatch in the operator handler.

[luser- -droog]

Every profile I take of xpost2 says the same thing: most of
the time is take by opexec. And opexec's big job is selecting
the appropriate operator function based on the types found
on the stack. It does this with a big, ugly "cond" structure
in a double loop.

So I'd like to sound-out a few thought on how to do this
"better". Please jump in if (when) I say something stupid.

I think I can simplify this if I arrange the type-codes so
the various patterns can be expressed by bitmasks.

So I divide the types into simple and composite:
_Simple_
invalid 000
null 001
mark 010
bool 011
name 100
save 101
int 110
real 111

_Composite_
string 1000
<unused> 1001
dict 1010
file 1011
array 1100

And the "executable" flag is bit 5.

So the "number" pattern is &6.
the "composite" pattern is &8.
"executable composite" is &24.
"executable composite, but not array" is t&24 && !(t&4).

But I'm still hung-up on a good way to do the "implicit float"
operation. For math operators that always return a real but accept
either a real or an int, the simple thing to do is write
one real->real function and pre-promote any int to real
before calling. But this doesn't seem to fit well into this
evolving bitop automaton.

[luser- -droog]

Also, instead of looping down the stack, I plan to peel-off
a "type digest" of the top 8 type bytes (padded with invalid),
so I can match a pattern with 2 32bit operations, virtually
eliminating one of the loops (still need to loop through
the patterns, tho).

Ps. I need more than a mask for the matches above.
Where there are more than one bit in the pattern,
I'll need to mask AND check for equality.
So the "number" test is not t&6 but (t&6)==6.