Consider how to properly expose private api object keys names for use in minimal interface

Right now in client_impl.py we have string literals that (re)define the key names of the keys of objects sent and returned to the private api, as shown below:

https://github.com/biocore/microsetta-private-api/blob/c88f2d88adfc14eb0bee9f0414215f609516afd4/microsetta_private_api/example/client_impl.py#L48-L53

Note that this code is also (re)defining which of these keys are writeable in the private api!

In reality, the gold-standard definitions of these values are made in the private api, but since the client has no way to ask the private api for them, it currently has to *duplicate* those definitions. This is fragile since If the values changed in the api, the client would break.

This is yuck, and we should come up with a better way ... could add endpoints to the private api to provide this info, or could create a python module in the private api that we assert we are willing to expose with external users and put these values in there. Or maybe something cleverer than these?

Start with client_impl.py lines 48-53 and trace where the private API defines the corresponding object keys and writable fields. Compare exposing this metadata through API endpoints with exposing an approved Python module, then establish which approach prevents the client from duplicating definitions. Done means the minimal interface can obtain these names and writeability rules without fragile duplicate literals.

Written by the indexing model from the issue text.