Subqueries in simple `delete_instance()` calls
Fixed by 08c595a
 Hi @coleifer,

Has this issue regressed at some point in version 3.x.x? We're looking to upgrade to the latest version of peewee and we're once again seeing deletion queries of this form when calling recursive deletes:

```
DELETE FROM "table2" WHERE ("foreign_field" IN (SELECT "t1"."id" FROM "table1" AS "t1" WHERE ("t1"."id" = ?)))
```
 Fixed (again)!
> We've been using peewee for quite a while now and have noticed from time-to-time that peewee generates delete (and update for nullables) queries of the form:
> 
> ``` sql
> UPDATE `table` SET `field` = null 
> WHERE (`table`.`field` IN (
>     SELECT `t2`.`id` FROM `othertable` AS t2 WHERE (`t2`.`id` = 1234)))
> ```
> 
> Earlier today I was debugging a slowdown on a table of approx 11 million rows in MySQL, when I noticed that the above SQL, if run without the subquery, drops from approx 20s to a few ms. Is there a reason that peewee generates foreign key updates/deletions with this form vs a direct 'table.field = 1234'? I was thinking of submitting a PR to change peewee to use the more direct SQL form, but I want to make sure I fully understand the problem space before addressing it this way.

My response:

> The reason they're generated this way is because when you call `delete_instance()` Peewee generates a dependency graph. As the graph is traversed, peewee progressively builds more complex subqueries. This works, but I can see how in the simple case we could get away with a simple equality check.
