Fault injection and chaos tests for the pool

[benoitc]

Builds on #928 and carries its two commits, so this should land after it (a rebase drops them). Only the last commit is new here.

Integration tests only exercise servers that answer, so nothing covered a connection that stalls, crashes, or dies mid-checkout, which is the shape of #927. Adds:

• hackney_fault_transport, a transport that behaves like hackney_tcp until a fault is armed per callback ({sleep, Ms}, {slow_error, Ms}, {hang, Ms}, {error, Reason}, crash), so faulted connections still talk to a real server.
• hackney_crash_sentinel, a logger handler that makes a dead pool visible under error_logger:tty(false).
• hackney_pool_fault_tests, one fault per scenario across the checkout entry points, asserting the caller gets an error, the pool is the same pid it was, nothing is left checked out or queued, and no connection leaked.
• hackney_pool_chaos_tests, concurrent workers with a monkey rotating the fault matrix underneath, scalable for a release soak with HACKNEY_CHAOS_WORKERS and HACKNEY_CHAOS_ROUNDS.
• hackney_pool_safety_tests, which walks the compiled abstract code and fails on any call from the pool into a connection process that is not inside a try.

The structural test found four live instances of the same class as #927: three unguarded hackney_conn:set_owner/2 calls and the prewarm dial. They now go through guarded helpers.

The hang scenario found a second problem that #928 makes more likely: stop_conn used gen_statem:stop/1, which waits forever, so after a dial timed out the pool blocked on stopping the wedged connection for as long as the transport took to return. Adds hackney_conn:stop/2 and bounds the pool's stop at 100ms, killing past the deadline. That scenario went from 1500ms to 152ms.

Full eunit is green (1090), xref and dialyzer clean. The fault suite fails on plain master in the expected ways.

[benoitc]

Extended to the multiplexed checkout paths in 721cf78.

h2_conn_usable/1 carried a comment claiming a short timeout but called hackney_conn:get_state/1, which waits the 5s default, so a single wedged HTTP/2 connection stalled the pool for 5s on every checkout for that host. is_ready, checkin_info and set_owner had the same exposure. All four now take an explicit timeout and the pool passes 250ms.

hackney_pool_h2h3_fault_tests wedges a registered connection with sys:suspend/1 and fails if the pool waits on it. Before the change that scenario hit the eunit timeout; it now answers none in 252ms.