The recently added code to try and optimize certain binary operations
when both operands were equal had a subtle bug.

Specifically, when that optimization applied, it failed to initialize
the hash table element returned from the failed lookup.   That hash
table element would be kept in the empty/uninitialized state which has
special meaning...

Under the right set of circumstances that could result in items being in
the hash table that we couldn't lookup (we could find them via a
traversal though).

The sequence of events from the BZ testcase looks like this:

Enter object1 into slot X
Enter object2 into slot Y (after rehashing due to conflict)

Y must be < X to trigger the bug because the next step requires a
reallocation of the table.  WHen we reallocate we walk through the old
table from first to last and insert the objects into the new table.

That results in object2 going into slot X and object1 going into slot Y
in the new table.

Then we remove object2 from the hash table.  This leaves slot X in a
deleted state.

Then we lookup object3 and get back slot X which will be put into an
empty state.  Since we didn't get a hit in the table, we try to lookup
an alternate form that would allow us to prove object3 has a constant
value.  That succeeds and we never re-initialize slot X, leaving it in
the deleted state.

The deleted state is important as it also means uninitialized.  The
generic bits of hash-table.h (reasonably) assume that a slot in the
empty/uninitialized state  implies that no other objects with a
conflicting hash are in the table.

So when we try to lookup object1 in the table, it misses because slot1
is uninitialized/empty -- which triggers the assert as we know object1
must be in the hash table.

[ Yes, I could almost certainly trigger this in a simpler way. ]

The fix is to ensure we initialize the slot properly after a miss, but
when we are able to prove the expression has a constant value.

Bootstrapped and regression tested on x86_64.  Installed on the trunk.

Jeff