HPCC-12642 Add link/Release implementations that are not thread safe

Signed-off-by: Gavin Halliday <gavin.halliday@lexisnexis.com>
If implemented addToFreeList was stupid enough to do, e.g. Linked<...> = this; directly or indirectly, this would end up with a infinitely recursive call..

Still feels like we should be able to encapsulate addToFreeList and beforeDispose into a single virtual action.

If we could reinstate the correct count after a beforeDispose that had returned false (don't dispose) could that work?
Could we subtract DEAD_PSEUDO_COUNT (using __sync_add_and_fetch) to restore a valid count?

Btw, am I right in thinking the atomic_cas testing for 0 is not strictly necessary? Once the count has gone to 0, anything that manipulated it before the cas, would have to be inherently thread unsafe code.. ?