Cleanup dto::Key and SKVRecord user interfaces

[jfunston]

Currently we expose the dto::Key in the user level SKV interface. It is used as an option for read requests and for partial updates to specify the key. The goal was to use it as an optimization so that key fields do not need to be serialized many times into SKVRecords. Internally, dto::Key is used for routing requests and in the server indexer. Ideally, the user interface should consistently use SKVRecords and not dto::Key which makes it easier to understand and lets the user interact with the individual fields of the key instead of as a blob in the dto::Key. Some considerations:

• We want to keep the optimizations that dto::Key provides us, in that it prevents extra serializations of values and can be serialized itself efficiently.
• How should the partialUpdate API look? It probably isn't clear to use two SKVRecords in the API, one for the key and one for the data
• If we find a good way to split the key and value fields in SKVRecord, we want to be able to use it to prevent data duplication on the server. Right now the serialized key fields in the fieldData payload are duplicated for every MVCC record.
• How does this interact with other uses for SKVRecords and schemas, particularly how do we want to handle returning aggregation results which will not match any existing schema.
• Can we make getSKVKeyRecord() cheaper and more like a view on the whole record? Currently it requires iterating over all of the key fields in order to truncate fieldData payload.