draft code with function signature and serialization, as reference as needed

[deigen]

This is some code I came up with for (a) data serializers based on type, and (b) method signatures that can be used to align data fields with arguments. They are each independently up and running, but not put together. Note: there are different files, which I named using v1 and v2, for my two attempts at possible approaches so far. They aren't pieced together yet and neither one handles everything.

I also think they are too fancy, and might be difficult to maintain. Serializing using the runtime types (and checking the inspect arg types just for final casting the inputs), as is now done in #516 will be a simpler approach, particularly to start.

However, there are some cases where extracting a signature could make sense:

1. In the web UI to provide input/output fields in the model demo page
2. UI-based documentation of fields
3. To dissociate the exact interdependence between client and server serialization's use of Data message fields: In the first few versions of this, it's OK for the client and server to assume each other's field<->arg mappings. But eventually, there may be changes that break these exact mappings. In this case, a signature declaring which python args go to which data fields using a field signature would enable more compatibility.

[zeiler]

what would an iterator look like to handle more than just the unary-unary case?

[zeiler]

is that what method_type is for? I see it being an int here, in a constant as UNARY_UNARY which matches some of the protos and the 'predict' in another spot.

[zeiler]

i'm not sure I understand the difference betwee v1 and v2 without reading through everything