feat: extract standalone waitForConfirmation from inline poll logic

[Yerimahjr]

Summary

Adds an exported waitForConfirmation(rpcUrl, txHash, options?) for callers who submit a transaction outside StreamsModule and still want the SDK's poll-until-confirmed behavior, and removes the duplicated poll loop by having invokeContract and StreamsModule share one implementation.

Closes #799

Changes

• waitForConfirmation (in src/soroban.ts, exported from the package root): resolves with { hash, returnValue } once the transaction succeeds. Rejects with an Error if it fails, ConfirmationTimeoutError if it doesn't confirm within maxAttempts, an AbortError if signal aborts, and RateLimitError (or the underlying error) on RPC failure. Options: pollIntervalMs, maxAttempts, signal.
• pollForConfirmation (internal): the single poll loop. It reports the outcome (success / failed / timeout / poll-error) instead of deciding what to throw, so each caller keeps its own policy.
• invokeContract and StreamsModule._sendAndPoll now call it and map outcomes exactly as before (invokeContract still resolves a pending hash unless strict; _sendAndPoll still throws). The now-unused sleep in streams.ts is removed.
• Docs (docs/api.md) and CHANGELOG.md.

Notes

• No behavior change for existing callers. One small difference: an already-aborted signal now throws before the first wait rather than after it (same AbortError).
• src/batch-tx.ts has a third poll loop that records per-transaction outcome objects rather than throwing; I left it alone since folding it in needs a different refactor.
• The issue's title shows waitForConfirmation(txHash, signal?) while its suggested approach shows (rpcUrl, txHash, options?); this follows the latter, with signal inside options.

Testing

• New src/tests/wait-for-confirmation.test.ts (10 tests): success with return value, polling through NOT_FOUND, default and custom intervals, failure, timeout, abort mid-wait and pre-aborted, RPC error passthrough, and 429 mapped to RateLimitError.
• Existing confirmation, rate-limit, streams and batch tests still pass (126 across the affected files); tsc --noEmit is clean.
• The full suite has 8 pre-existing failures (factory, governor, relayer-stress) that fail identically on a clean upstream/main; eslint's one error (any in streams.ts) also exists there.

[drips-wave]

@Yerimahjr Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits