PERF: Investigate optimized rows affected round-tripping when batching

[anpete]

We currently do this kind of thing:

UPDATE [world] SET [randomnumber] = @p0
WHERE [id] = @p1;
SELECT @@ROWCOUNT;

UPDATE [world] SET [randomnumber] = @p2
WHERE [id] = @p3;
SELECT @@ROWCOUNT;

UPDATE [world] SET [randomnumber] = @p4
WHERE [id] = @p5;
SELECT @@ROWCOUNT;

This approach means we have to call NextResult for each statement. We should see if there is faster way, perhaps involving just a single reader MoveNext.

[ajcvickers]

We should check that there is real benefit if we decide to pursue this.

[AndriySvyryd]

Also, we don't even need this for inserts

[roji]

For deletions, we have design for bulk delete which would return the IDs of deleted rows in a single resultset (#27550 (comment)).
For insertions this isn't necessary (rows are either inserted, or an error occurs)

For updates, we may be able to use MERGE for bulk updates on SQL Server - benchmark this.

Note that since #27547, we no longer do a separate query for concurrency checking, but use a RETURNING/OUTPUT clause. That still generates a resultset per change.