gl-signerproxy: Fix concurrent HSM request blocking via message-passing dispatcher

[cdecker]

Problem

gl-signerproxy shared a single current_thread Tokio runtime across all OS
handler threads via Arc<Runtime>. current_thread only allows one concurrent
block_on caller — when onchaind's thread called block_on(server.request(...))
for a type 143 (SIGN_ANY_REMOTE_HTLC_TO_US) request and blocked indefinitely
(no signer connected), every other handler thread was serialised behind it:

• Type 27 init requests from other subdaemons had to wait
• The type 143 gRPC call never reached the plugin's stager.requests
• stuck_request_types() always returned empty
• The bgsync session ran the full 10-minute timeout instead of aborting early

Fix

Keep a single Tokio runtime but remove direct block_on calls from handler
threads. A GrpcMessage enum carries either a ping or a forwarded HSM request,
each with a oneshot::Sender for the reply. An mpsc channel feeds a dedicated
async grpc_dispatcher that tokio::spawns each message as an independent task.
Handler threads call blocking_send / blocking_recv — fully concurrent; a
permanently-stuck type 143 task can no longer delay any other task.

With this change, type 143 requests reach the plugin stager, stuck_request_types()
detects them, and the bgsync session aborts within 10 seconds.

Test

type_143_lockup_does_not_block_other_requests — two connections share a mock
dispatcher where type 143 sleeps for 60 s. The test confirms that a type 27
request on the second connection receives its response in well under 5 seconds
despite the concurrent blocked type 143.

Test plan

• cargo test -p gl-signerproxy passes (regression test runs in ~0.15 s)
• cargo check -p gl-signerproxy clean
• Integration: bgsync session log shows stuck_request_types: [143] and
  early-abort within 10 s when a node is stuck on an onchaind type 143 request