opt: use best-effort locking for SFU subquery of mutation

For queries that both lock and mutate exactly the same set of rows (typically using `SELECT FOR UPDATE` as a subquery), we do not need to use guaranteed-durable locks under read committed isolation, because the intents laid by mutations will act as durable locks.

For example, in this case the `SELECT FOR UPDATE` subquery could use best-effort locking instead of guaranteed-durable locking:

```sql
CREATE TABLE abc (
a INT NOT NULL,
b INT NOT NULL,
c INT NOT NULL,
PRIMARY KEY (a)
);

INSERT INTO abc SELECT i, i, i FROM generate_series(0, 9) s(i);

EXPLAIN
UPDATE abc SET b = 19, c = 19
FROM (SELECT a AS aa, b AS bb, c AS cc FROM abc WHERE a = 9 FOR UPDATE)
WHERE a = aa
RETURNING aa, a, bb, b, cc, c;
```

The current plan uses guaranteed-durable locking:

```
demo@127.0.0.1:26257/demoapp/defaultdb> EXPLAIN
-> UPDATE abc SET b = 19, c = 19
-> FROM (SELECT a AS aa, b AS bb, c AS cc FROM abc WHERE a = 9 FOR UPDATE)
-> WHERE a = aa
-> RETURNING aa, a, bb, b, cc, c;
info
------------------------------------------------
distribution: local
vectorized: true

• update
│ table: abc
│ set: b, c
│ auto commit
│
└── • render
│
└── • lookup join
│ table: abc@abc_pkey
│ equality: (a) = (a)
│ equality cols are key
│
└── • scan
missing stats
table: abc@abc_pkey
spans: [/9 - /9]
locking strength: for update
locking durability: guaranteed
(21 rows)

Time: 4ms total (execution 4ms / network 0ms)
```

Jira issue: CRDB-28600
Epic CRDB-38938