feat: support read lock mode for R/W transactions

[shobhitsg]

Samples and integration tests will be added in separate PRs.

[olavloite]

What does this sentence mean?

This mode primarily applies to transactions with {@code SERIALIZABLE} isolation.

That it has no effect on RR? Or that it has a strong effect on Serializable?

What I'm aiming at is: Can we make this more concrete? As a customer, I would have no idea what this means.

[shobhitsg]

I've updated the doc. Currently, we do not allow setting the readLockMode for Repeatable Read(RR) isolation level and error will be returned. And by default, OPTIMISTIC lock mode will be used for RR.

[olavloite]

Can we also add some generic advice when to use what? (Otherwise, I think that most users will automatically assume that 'optimistic is always better than pessimistic').

So for example something like this:

Suggested change

	*
	* Optimistic locking can improve throughput, as transactions wait with taking locks until they try to commit,
	* but increases the probability that Spanner needs to abort a transaction due to lock conflicts. Pessimistic
	* locking instructs transactions to take locks earlier, which means that concurrent transactions might have
	* to wait for other transactions to release locks before proceeding. Pessimistic locking reduces the probability
	* that Spanner needs to abort a transaction due to lock conflicts.

[shobhitsg]

I initially added some advice to the document but removed it because I felt it deserved a more detailed explanation in a separate link. I've now added the advice back, and we will update this document once the RR + Pessimistic feature is launched.

[shobhitsg]

@sakthivelmanii @olavloite: I've addressed the review comments. PTAL.