FDB client utilities library

Following is the dependency situation for FDB client-side code.

`fdb_c` ➡ `fdbclient` ➡ `fdbrpc` ➡ `flow`

`fdb_flow` ➡ `fdb_c` and `flow`

Even though fdb_flow depends on fdbclient, fdb_c hides fdbclient behind multi-version client and all. Doesn't expose anything inside fdbclient to fdb_flow. fdbclient is dealing with lower level `ReadYourWriteTransaction` and fdb_flow deals with `TransactionImpl` which goes through fdb_c. If you disregard this difference, there is so much duplicate code between these two libraries. FDBLoanerTypes and FDBTypes are pretty much the same. We have two implementations of Tuple layer in Flow, one for each library. There are features in fdb_flow that can be used from fdbclient, and vice-versa. By using ReadYourWritesTransaciton, backup and restore code has become non-portable.

We can benefit by refactoring this a bit. With #1215, we will have a very generic Transaction interface. We could keep this interface in a separate library and make both fdb_flow transaction and ReadYourWriteTransaction implement it. Then, we can move all the generic code into this new library. That way, both these libraries can share the code without any code duplication.

NOTE: We have to be careful while removing these duplicate copies. Even though they are achieving the same goal, it's not necessarily the exact same code. This is a very good reason to work on this task. Although, a small difference in Tuple encoding in the implementations can introduce interesting update bugs and corruptions.

Start by reading the dependency chain in the issue and the proposed generic Transaction interface from #1215. Compare FDBLoanerTypes, FDBTypes, and the two Tuple implementations before deciding what can be shared. Done means a separate shared library removes generic duplication without changing tuple encoding or transaction behavior.

Written by the indexing model from the issue text.