kvs: string/JSON values should not be stored with NULL termination

[garlick]

The KVS internally represents all values as an opaque byte sequence. The server side does not interpret them in any way, however the API side has a convention about NULL terminating strings that complicates append support proposed in #1193.

flux_kvs_txn_put() stores a C string into the KVS with its terminating NULL. This allows flux_kvs_lookup_get() to directly return value without the need re-copy to a size + 1 buffer to add a NULL to it, or so went the logic at the time (now somewhat outdated).

The JSON API functions use the same convention so that a JSON value written with flux_kvs_txn_pack() can be read out in encoded form with flux_kvs_lookup_get().

This complicates append support. If string values are concatenated by repeatedly calling flux_kvs_txn_put(FLUX_KVS_APPEND), there is no mechanism for the server to remove the NULL terminators at the end of each blob.

Let's stop storing the NULL. Looks like we can just change treeobj_decode_val() so that when it de-base64's a value, it tacks on an extra NULL byte to the decode buffer without including it in the returned length. Then the value can be used direclty as a string if desired. When we call treeobj_create_val() to encode a string, we pass the string length, not string length + 1.