sql: delete from query hangs

**Describe the problem**

During some randomized testing I encountered a delete query that appears to hang (though it's more likely unnecessarily slow).

**To Reproduce**

```
CREATE TABLE t (i INT);
INSERT INTO t(i) SELECT * FROM generate_series(1,100);
DELETE FROM
t AS tab_1
USING
t AS tab_2,
t AS tab_3,
t AS tab_4,
t AS tab_5
WHERE
true;
```

In the explain, it looks like there are a lot of inner joins and full table scans:
```
root@127.0.0.1:26257/defaultdb> EXPLAIN(OPT) DELETE FROM
-> t AS tab_1
-> USING
-> t AS tab_2,
-> t AS tab_3,
-> t AS tab_4,
-> t AS tab_5
-> WHERE
-> true;
info
----------------------------------------------------------
delete t [as=tab_1]
└── distinct-on
├── inner-join (cross)
│ ├── inner-join (cross)
│ │ ├── inner-join (cross)
│ │ │ ├── inner-join (cross)
│ │ │ │ ├── scan t [as=tab_4]
│ │ │ │ ├── scan t [as=tab_5]
│ │ │ │ └── filters (true)
│ │ │ ├── scan t [as=tab_3]
│ │ │ └── filters (true)
│ │ ├── scan t [as=tab_2]
│ │ └── filters (true)
│ ├── scan t [as=tab_1]
│ └── filters (true)
└── aggregations
├── first-agg
│ └── tab_2.i
├── first-agg
│ └── tab_2.rowid
├── first-agg
│ └── tab_2.crdb_internal_mvcc_timestamp
├── first-agg
│ └── tab_2.tableoid
├── first-agg
│ └── tab_3.i
├── first-agg
│ └── tab_3.rowid
├── first-agg
│ └── tab_3.crdb_internal_mvcc_timestamp
├── first-agg
│ └── tab_3.tableoid
├── first-agg
│ └── tab_4.i
├── first-agg
│ └── tab_4.rowid
├── first-agg
│ └── tab_4.crdb_internal_mvcc_timestamp
├── first-agg
│ └── tab_4.tableoid
├── first-agg
│ └── tab_5.i
├── first-agg
│ └── tab_5.rowid
├── first-agg
│ └── tab_5.crdb_internal_mvcc_timestamp
└── first-agg
└── tab_5.tableoid
```

**Expected behavior**
This query seems like it could be optimized, since the query is not actually using any data from any of the `USING` tables. Then the cross joins and scans would be eliminated from the plan.

**Environment:**
This behavior exists on v23.2+ (didn't test on v23.1)

Jira issue: CRDB-41364

Start by running the supplied CREATE TABLE, INSERT, DELETE, and EXPLAIN(OPT) statements to reproduce the plan. Investigate why unused USING tables produce cross joins and full scans; done means the equivalent DELETE plan omits those scans and the query no longer appears unnecessarily slow.

Written by the indexing model from the issue text.