Fix data races in connection lifecycle code (TSAN findings, #460)

[p-alik]

Summary

Addresses a scoped subset of the data races reported in #460 (found via TSAN while validating #459):

• is_dead, io_list, proc_list, proc_removed, to_be_freed_list on gearman_server_con_st are set by one thread (e.g. IO thread) and polled by another (proc/main thread) with no synchronization at all in several places. Converted to std::atomic<bool>.
• _thread_packet_flush() walked con->io_packet_list (dereferencing ->packet/->next) without a lock, while the producer (gearman_server_io_packet_add()) always appends under con->thread->lock. Now the head pointer/->next are read under that lock before use.
• gearman_server_con_to_be_freed_next() had an unlocked pre-check reading thread->to_be_freed_list before acquiring the same lock the writer always uses. Removed the pre-check.

This is deliberately scoped to the 3 representative races called out in the issue body plus the same-pattern flags — it does not touch the intentionally-racy performance fast-paths mentioned in the issue's "other race sites" list (dcon_add_count, io_count/proc_count wakeup checks), matching the discussion in the issue that broad changes shouldn't be packed into 2.0.0.

Test plan

• Normal build compiles cleanly with no new warnings.
• Built with -fsanitize=thread (CXXFLAGS='-fsanitize=thread -g -O1') in an isolated tree.
• Ran gearmand --threads=4 under TSAN, hammered with 16 concurrent gearman clients submitting 300 background jobs each (4800 total, no worker — mirrors the issue's repro).
• Confirmed none of the fixed race sites (is_dead, io_packet_list, to_be_freed_next pre-check) reproduce anymore; remaining TSAN reports are exactly the intentionally-unlocked fast-paths and a con->ret race not named in the issue, left out of scope for this PR.

Closes part of #460 (leaves the documented "other race sites" list for a follow-up).