feat: commit begins transaction if not already begun

[devjgm]

Fixes #689

---

This change is 

[codecov]

Codecov Report

Merging #1143 into master will increase coverage by 0.02%.
The diff coverage is 94.87%.

@@            Coverage Diff            @@
##           master   #1143      +/-   ##
=========================================
+ Coverage   93.58%   93.6%   +0.02%     
=========================================
  Files         169     170       +1     
  Lines       13065   13110      +45     
=========================================
+ Hits        12227   12272      +45     
  Misses        838     838

Impacted Files	Coverage Δ
google/cloud/spanner/internal/connection_impl.cc	97% <100%> (+0.29%)	⬆️
...gle/cloud/spanner/internal/connection_impl_test.cc	98.82% <93.65%> (+0.03%)	⬆️
...loud/spanner/internal/partial_result_set_resume.cc	90.9% <0%> (-4.55%)	⬇️
...ud/spanner/integration_tests/client_stress_test.cc	82.45% <0%> (-0.88%)	⬇️
google/cloud/spanner/transaction.h	100% <0%> (ø)	⬆️
google/cloud/spanner/database_admin_connection.h	100% <0%> (ø)
.../spanner/benchmarks/multiple_rows_cpu_benchmark.cc	64.05% <0%> (+0.03%)	⬆️
google/cloud/spanner/internal/spanner_stub.cc	68.13% <0%> (+1.09%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fb5edf1...4da2699. Read the comment docs.

[devbww]

Even though it doesn't make sense to pass a single-use/read-only transaction to Commit(), it also doesn't make sense to pass any read-only transaction, yet we support the latter and not the former. So, we might as well look at s.has_single_use() and use its TransactionOptions, rather than using the default TransactionOptions, and let the chips fall where they may.

[devjgm]

I wouldn't say that we "support" read-only transactions. Any caller who passes in a read-only transaction to Commit() will get an error. I believe that's true before and after this PR.

To call Commit() correctly, callers must pass in a read-write transaction. RW transactions have all their options in the "begin" field of the selector, so that's why I think we only need to copy that field from the selector into the mutable_options in the request.

I don't think we should write extra code to deal with things like single-use RO transactions when callers are not allowed to pass them, and if they did, it's guaranteed to fail.

[devjgm]

Discussed this offline. I changed the code to consider the case where the input selector was a single_use transaction as @devbww was suggesting. We know this will give an error, but it's what the user asked for.