Request: recovery method when a commit aborts at the RPC level

Request for enhanced concurrent transaction handling in Cloud Spanner Emulator to support testing scenarios with gRPC interceptor-based fault injection.

## Background

We are migrating our unit tests from production Spanner to Spanner Emulator. Our existing tests use an internal fault injection library that intercepts gRPC calls at the client level to verify proper handling of Abort errors.

## Current Problem

The emulator's current constraint ([README](https://github.com/GoogleCloudPlatform/cloud-spanner-emulator/blob/master/README.md#features-and-limitations)):
> The emulator only allows one read-write transaction or schema change at a time. Any concurrent transaction will be aborted.

When our fault injection tool returns an Abort error **before** the actual Commit RPC reaches the emulator:
1. The RPC never reaches the emulator
2. The original transaction remains open in the emulator (not committed/rolled back)
3. Retry attempts cannot start new transactions due to the "one RW transaction at a time" constraint
4. Tests fail regardless of correct retry implementation

## Current Workaround

Use `--enable_fault_injection` option instead.
However, there are some complaints.

- **Non-deterministic**: Cannot reliably reproduce specific failure scenarios
- **Development workflow**: Difficult to debug retry logic

We would prefer to maintain our current approach if possible.

## IMHO

I'm not familiar with the inner mechanics of Spanner Emulator, but I think it would be nice if it had a mode like this.

Last-Tx-Wins Mode (current behavior is First-Tx-Win Mode)
Add an option (e.g., `--transaction_last_wins`).
New RW transactions automatically abort/rollback previous uncommitted transactions.

Of course, other methods are fine too, and it would be even better if it behaved exactly like the real Spanner.