Improve Ctrl+C responsiveness during future polling

[lipeize689-prog]

Summary

This PR improves how Sherlock responds to Ctrl+C during active username checks.

Previously, Sherlock could remain blocked while waiting for a single future to finish, which made interruption feel delayed during long-running searches. This change makes future polling more interruptible and adds cleanup for pending work when a keyboard interrupt occurs.

What changed

• Changed future result handling in get_response() to use short-interval polling via request_future.result(timeout=0.1) instead of waiting indefinitely for a single future.

• Preserved KeyboardInterrupt so user interruption is propagated instead of being absorbed into ordinary request error handling.

• Added shutdown_request_session() to:
  cancel not-yet-started futures when possible,
  shut down the executor,
  close the underlying requests session.

• Updated the query flow in sherlock() so interruptions trigger cleanup before bubbling back to the main CLI flow.
  Kept the main interrupt path centered around handler() and the CLI flow in main(), so users still receive a clear interruption message and exit path.

Why this matters

It improves interactive behavior during concurrent site checks by reducing the amount of time Sherlock can remain stuck waiting on a single future before reacting to Ctrl+C.

It does not forcibly terminate already-running worker threads, but it does:

reduce time spent blocking on one future,
make interruption more responsive,
and clean up pending work more reliably.

Testing

Added/used targeted tests covering:

KeyboardInterrupt propagation during future polling,
cancellation/cleanup logic in shutdown_request_session(),
main CLI interruption behavior through the updated Ctrl+C path.
Targeted test result:

6 passed, 7 deselected