Avoid optimistic updates for explicit readwrite transactions

[dfahlander]

Never let an 'rw' transaction leak information to live queries before the transaction commits. Even if liveQueries could benefit from optimistic updates, never let them through if they origin from an explicit 'rw' transaction. Instead let the liveQuery update when the 'rw' transaction commits. Still allow optimistic updates from "transactionless" operations such as db.friends.update({name: 'Bar'}) without a transaction block around.

In normal situations, there's no much benefit from optimistic updates with IndexedDB since the transactions are fast and local anyway. However, in case a long-running transaction is locking the database, and you are showing an editable field component, it can be nice that the user updates are immediately propagated to the view no matter whether a transaction is locking a table. Notice that in case the optimistic update finally fails when its transaction commits (all operations have implicit transactions in backround), the optimistic update will be reverted.

We could also just skip the whole optimistic feature in its whole and only take the benefits we have with the cache. But for 2 reasons, I want to keep it.

First for the sake of immediate view updates from simple update / put / add / delete operations.
Second because we need to computations anyway if we want to optimize paged offset/limit queries in future.