Switch the atomicAdd to an atomicInc.

Didn't know 'increment' existed, earlier.  This should address the
problem with potentially empty/incorrect 'holes' in pending.  That
doesn't affect correctness, but makes it much simpler to explain.
Fix the bug iterating/deleting entries from the HT.

The issue actually turned out to be the incorrect marking of
remove_entry as a PURE function.  PURE is only for functions which
produce a value; any function which modifies its argument
can/should not be pure.

Oops.

Also managed to break the non-naive based kernel, somehow.  It
seems to never copy any values into the global HT mem...
Go back to an atomicAdd for the pidx increase.

The increment verifies the value hasn't changed, but it turns out
that there's *tons* of contention and the value changes often---so
the update often gets lost with an increment.
Don't try to flush more values than we have!

When multiple threads insert, one thread can reach this flush
while other threads are still trying to insert into the local
buffer.  In that case, pidx can exceed PENDING.  This makes sure
we don't try to run off our array.
Make sure to cap 'pending' access, performance.

The CAS is needed because an Inc could come in between those, and
it would thus never get reset.
'Fix' the performance issue.

Not really, it's still slower.  But a lot less slower, this way.