Use string keys for everything in the json-ld.api namespace

[cap10morgan]

We're running into recurring bugs w/ JSON requests because our internal API fns want keywords but the JSON-LD keys need to remain strings even after deserialization. So we should just change our API fns to accept string keys for everything and then add a thin CLJ SDK wrapper that accepts keywords, string-ifies them, and then passes that to the corresponding API fn.

Open question: Should we do any keyword-ification of return values in the CLJ SDK wrapper? Perhaps keys defined by us (i.e. not in user data; things like t, commit in transaction responses, address, alias in ledger create responses, etc.) and then user data keys based on the supplied context (i.e. if it uses keywords or not)? OR we could just have a bool keyword-response-keys? or similar option that tries to keywordize everything or throw an error if anything wouldn't be a valid keyword (or just leave it as a string).

[bplatz]

Open question: Should we do any keyword-ification of return values in the CLJ SDK wrapper? Perhaps keys defined by us (i.e. not in user data; things like t, commit in transaction responses, address, alias in ledger create responses, etc.)

I think we should for metadata-like keys we might return with an API response, but not touch any "data payloads". Using query as an example, query responses are pure data by default, but we have the :meta? option (or something like that) that can optionally return an outer map with execution time, fuel, etc. I think those are a handful of keys and easy to keywordify, and what a CLJ dev would expect to see.

We still would retain the ability to use keyword-based contexts... so if you wanted your payload keyword-ified as well you can do that... but our default handling is always the actual context, which is string-based.

[cap10morgan]

Not doing this after all