fix(spanner): ensure active transaction is rolled back on exception

[cy-yun]

This PR addresses an issue in Cloud Spanner where an active transaction might leak if an exception is thrown during the Database::runTransaction callback.

Previously, if a user-provided callback threw an exception, the exception would bubble up without explicitly rolling back the transaction. This PR catches any \Throwable thrown by the callback, checks if the transaction is still active, and explicitly issues a rollback to the Spanner backend before re-throwing the exception.

Additional Fixes

While adding this, a latent bug was discovered and fixed:
Database::runTransaction was passing its configuration $options directly into $transaction->rollback($options). Since runTransaction options (like tag, isRetry, singleUse) are not valid CallOptions for Operation::rollback, this would cause an InvalidArgumentException (e.g., Unexpected option(s) provided: tag). This exception was masking the rollback failure and leaving the transaction un-rolled back on the server.
This PR fixes this by calling $transaction->rollback() without passing the runTransaction configuration options, ensuring the rollback completes successfully.

Testing

• testRunTransactionRollsBackOnException: Verifies that an exception in the callback triggers a rollback.
• testRunTransactionNoCommitWithTag: Verifies that passing tag to runTransaction no longer causes an InvalidArgumentException when the transaction must be rolled back at the end of execution.

[bshaffer]

Hmm, looking at this, I am not honestly sure this is the correct behavior. I see that we automatically roll back transactions already, so this seems appropriate

EDIT: oops, did not mean to request changes.