Implicit transaction in DatabasePool.write and DatabaseQueue.write

[groue]

This PR fixes an ergonomic issue with database pools and queues, and has them wrap database accesses in a transaction by default.

The problem is clear with database pools: unless writes are wrapped in a transaction, concurrent reads see partial changes. This is positively unsafe:

// Currently unsafe
try dbPool.write { db
    try Credit(destinationAccout, amount).insert(db)
    // <- Concurrent dbPool.read sees a partial db update here
    try Debit(sourceAccount, amount).insert(db)
}

// Current way to make it safe:
try dbPool.writeInTransaction { db
    try Credit(destinationAccout, amount).insert(db)
    try Debit(sourceAccount, amount).insert(db)
    return .commit
}

This subtlety in the concurrent behavior of database pools was abundantly documented. But personal experience with coworkers and frequent feedback from GRDB users have revealed that it was too high a burden to force users to remember to use transactions in nearly all their database pool writes.

The problem is less pressing with database queues, since serialization of database accesses prevents concurrent reads from fetching inconsistent database values. Yet, personal experience again reveals that users perform a constant and conscious effort in order to choose whether to use a transaction or not, or wonder if a transaction-less access hides a potential bug or not.

On top of that, the GRDB 2.0 API makes it painful to both run a transaction and extract values, leading to more opportunities to hesitate between transactions and convenience:

// Typical GRDB 2.0 code: meh
var count: Int! = nil
dbQueue.inTransaction { db in
    try ...
    count = try Player.fetchCount(db)
    return .commit
}
print(count)

Since GRDB is supposed to take care of concurrency difficulties so that developers can profit from the safest behavior without much thinking about it, something has to be done.

---

After this PR is merged:

• dbQueue.write and dbPool.write run inside a transaction.
• dbQueue.inTransaction and dbPool.writeInTransaction are still here, in order to support the various SQLite transaction types, and explicit rollbacks.
• dbQueue.inDatabase, which does not open a transaction, is now documented as an advanced method.
• A new method dbPool.writeWithoutTransaction is introduced, for the advanced use cases that need fine-grained transactions.

// After this PR is merged:

// BEGIN TRANSACTION
// INSERT INTO credits ...
// INSERT INTO debits ...
// COMMIT
try dbPool.write { db in  // or dbQueue.write
    try Credit(destinationAccout, amount).insert(db)
    try Debit(sourceAccount, amount).insert(db)
}

// BEGIN IMMEDIATE TRANSACTION
// INSERT INTO credits ...
// INSERT INTO debits ...
// COMMIT
try dbPool.writeInTransaction(.immediate) { db in  // or dbQueue.inTransaction
    try Credit(destinationAccout, amount).insert(db)
    try Debit(sourceAccount, amount).insert(db)
    return .commit
}

// INSERT INTO credits ...
// INSERT INTO debits ...
try dbPool.writeWithoutTransaction { db in // or dbQueue.inDatabase
    try Credit(destinationAccout, amount).insert(db)
    // <- Concurrent dbPool.read sees a partial db update here
    try Debit(sourceAccount, amount).insert(db)
}

[groue]

Thanks @mayurdzk and @sobri909 for the inspiration!