feat(ffi): protect unsafe concurrent ops

[alarso16]

The goal of this is to prevent potentially unintended side effects of using the most recent revision in a concurrent manner. This isn't intended to remove the burden of correct concurrency from the user, but prevent easy mistakes. We expect these invariants to hold, so why not guarantee it?

Closes #1473

[demosdemon]

I don't know if Go has any read-write locks in stdlib, but this is a case where we need it. Most of the operations with the database handle are safe to execute concurrently (e.g., read operations). And, reading is also safe to do concurrently while committing. However, dropping is not safe to do while there are any concurrent reads or ongoing commit. So, before we drop, we need to acquire a semaphore that waits for ongoing reads to complete and prevents future reads, a lock to prevent commits, and a lock to prevent concurrent drops (which is handled by the keepAliveHandle and also why I wanted to name the function withLock).

[alarso16]

I don't know if Go has any read-write locks in stdlib...

It does, my bad for not noticing this! I think I fixed this issue.

[demosdemon]

I think we also need to acquire the commit lock here. And should we rename it to commit lock? "State lock" is correct but wasn't my immediate thought when looking for it.