Align Execute...-methods with single-statement SaveChanges behaviour regarding transactions

I originally posted this as a comment on an older issue with the Pomelo MySql EF provider, but after getting some feedback from @roji , I'm creating this issue here instead, The current behavior is by design but could at least benefit from discussion, we agreed on. The original issue is [here](https://github.com/PomeloFoundation/Pomelo.EntityFrameworkCore.MySql/issues/1740).

When working with a MySQL server with the very unusual setting (which we can't change because a legacy system also using the database requires it) "set autocommit=0" (which works similarly to "SET IMPLICIT_TRANSACTIONS ON" in SQL Server), SQL statements executed by ExecuteDelete(...), ExecuteUpdate(...), ExecuteSql(...), and similar methods, are never committed unless we wrap them in explicit transactions (we only encountered it with ExecuteDeleteAsync and ExecuteSqlRaw, but if I understand @roji correctly, they probably all behave the same).

Since EF7, when SaveChanges(Async) generates a single statement, it is no longer wrapped in an explicit transaction, and the SQL Server provider mitigates the problem we experienced by issuing the command "SET IMPLICIT_TRANSACTIONS OFF" before the actual statements, and since I raised the issue mentioned below, the Pomelo MySQL provider issues the corresponding command (set autocommit=1).

Also, the Database.AutoTransactionBehavior property can be set to AutoTransactionBehavior.Always, which disables the optimization introduced in EF7.

Since the possibility of the unusual settiing is acknowledged and handled by the "single statement SaveChanges" feature, I feel that it should be treated similarly by the Execute(...) methods.

I'm not sure, but I suspect that always wrapping them in transactions would be a breaking change, and I *suspect* that automatically issuing a "SET IMPLICIT_TRANSACTIONS_OFF" or "set autocommit=1" would as well. So even if one of those would be my favourite solution, I assume they're off the table.

HOWEVER, I feel that it would at least be prudent to wrap the Execute(...) calls in explicit transactions (unless one is already in progress, of course) when the Database.AutoTransactionBehavior is set to Always, as that's very unlikely to be the case unless someone actually has the exact same problem (having to live with the unusual setting).

Thoughts?