Safety around `NextWriteNoWriteConflictRange` logic in parallel context.

[Speedy37]

Currently set_option only require a reference to the transaction to work.

This means it can be called by multiple thread in parallel without ownership of the transaction.
There is currently one option that concerns me: NextWriteNoWriteConflictRange

The next write performed on this transaction will not generate a write conflict range. As a result, other transactions which read the key(s) being modified by the next write will not conflict with this transaction. Care needs to be taken when using this option on a transaction that is shared between multiple threads. When setting this option, write conflict ranges will be disabled on the next write operation, regardless of what thread it is on.

There are multiple ways to prevent that :

• give access to a new API with mutex protection (add complexity on Transaction struct Option<Box<Mutex>>)
• protect the affected method/option by requiring a mutable reference to the transaction, safe but might create a pain to use it
• only protect NextWriteNoWriteConflictRange with a global (😒) mutex (or something clever)
• do nothing and let users handle that themselves