Fix data race on RspConnector lifetime

[xusheng6]

Fixes #1074

m_rspConnector is a raw pointer in the Gdb, Corellium and Esreven adapters, with no
synchronization on the read or the delete. A call already in flight can end up using a
freed connector. This is the top debugger crash cluster in Sentry (BINARYNINJA-4E, C1,
E1, E4, ...), which faults inside mtx_do_lock while locking m_socketLock on a dead
connector.

The existing null checks cannot fix this, because the pointer can be freed between the
check and the use.

Change

Wrap the field in AtomicRspConnector, a mutex-guarded shared_ptr. Callers load a
strong reference before use, and teardown just stores nullptr, so the connector is
destroyed only when the last reference drops.

This is 73e6517 from fix-rspconnector-lifetime-race, rebased onto dev. One conflict in
EsrevenAdapter::GetTTDCallsForSymbols, plus four places where the newer bare
!m_rspConnector guards were folded into the load()-then-check pattern.

Testing

test/repro/ adds an ASan driver that runs AddBreakpoint against Quit over a fake
RSP server. Same harness and settings both sides:

build	result
dev	use-after-free on the first iteration
this branch	25 iterations clean, no ASan report

The failing stack matches the Sentry reports: freed in GdbAdapter::Quit, read from
AddBreakpoint -> TransmitAndReceive -> SendPayload -> SendRaw.

[xusheng6]

@bdash would you please review this? I had a closer look at sentry, and it seems to me that it is still happening