Evaluate if StealRequest could be pointer object

[mratsim]

Having Steal Request as pointer objects with ownership passed by channels instead of deep copy might reduce the overhead of the framework:

• Lock-free MPSC list-based queues have a wealth of literature, this would avoids having to debug The MPSC channel has a deadlock #6 (though lock-free debugging is hard as well)
• A bitset for 256 victims takes 32 bytes, with the rest of the data, the StealRequest size becomes quite big.
• We could use a more efficient set suitable for random picking but that would use much more space (513 bytes instead of 32 for 256 max workers (Refactor the bitset data structure #5 (comment))

One useful thing is that steal request destruction only happen in the creating worker and since each steal requests maps to an unique task channel, we would know when the task is sent back, which steal request to destroy. Other worker can only dispose of their own steal requests.

This brings cheaper copy in the MPSC channel and easier lock-free implementation at the cost of a guaranteed cache miss when reading the steal request and potentially increased latency on NUMA.