EBP-3104: Add best-practice Python request-reply reference samples

[aelsammak]

What is the purpose of this change?

• Add 4 new Python samples for request reply
• Updated the naming scheme of samples to better fit the python public samples
  • blocking instead of using sync and no mention of async

How is this accomplished?

1. Added python-direct-requestor-blocking-sample.py: one publish_await_response() with a positive 3000 ms reply timeout and a single retry on PubSubTimeoutError (JCSMP parity), then self-exit.
2. Added python-direct-requestor-sample.py: five non-blocking publish() calls that each return a concurrent.futures.Future, so the requests are in flight together, then each Future is collected for its reply or its timeout.
3. Added python-direct-replier-sample.py: RequestReplyMessageReceiver built with the request topic subscription, receive_async() with a RequestMessageHandler that guards on a None replier, echoes APPLICATION_MESSAGE_ID, and catches a failed reply().
4. All three follow the EBP-3103 structure: shared connection-config helper, setup_solace / connect_solace / teardown with a populated state dataclass, service listeners before connect(), 3000 ms reconnect interval, SIGINT/SIGTERM shutdown, bounded terminate(). Exit code is 0 on success or a shutdown signal and 1 on a missing reply or a failure.
5. Renamed the four EBP-3103 samples to drop -async (for example python-direct-publisher-sample.py), including the "Copied into a generated project as" docstring line.
6. Corrected a stale comment in the guaranteed publisher that said the direct publisher pauses during a reconnect.

Anything reviews should focus on/be aware of?

• The request-reply builders expose no back-pressure setting and their from_properties() applies no property, so these samples carry no buffer capacity constant, unlike the EBP-3103 samples. The comments say so.
• publish_await_response() and Replier.reply() accept only an OutboundMessage, so these samples use the message builder where the direct publisher is builderless.
• Only the blocking requestor retries once; the non-blocking requestor does not retry per Future. Is that the right split?
• A shutdown signal during a blocking wait takes effect when the call returns, within the reply timeout.
• Naming rule: -blocking means the call waits for the broker's answer (a reply or an ACK), not a back-pressure wait. A future publish_await_acknowledgement() sample would be python-guaranteed-publisher-blocking-sample.py.
• Nothing routes to these files yet (SKILL.md, mode files, and evals are out of scope), so trigger and output evals were not run.

Verification (solace-pubsubplus 1.11.0, Python 3.13, local broker):

• pyflakes clean on all Python samples
• No-broker smoke test: 10/10 (imports, build before connect, teardown of an unconnected state, refused connect with clean teardown)
• Live: replier + blocking requestor exit 0 with the correlated reply; replier + non-blocking requestor 5/5 replies, exit 0; replier SIGTERM exit 0
• No replier: blocking requestor exits 1 after the retry (~6 s), non-blocking exits 1 (~4 s); SIGINT during the blocking wait exits 0

[mtite-sol]

Changes LGTM! Might be worth considering adding automated testing in the future to cover at least what you mentioned in your smoke tests. This can give us more confidence that samples still work when updating code / updating api version. Not needed for this PR though!