Build Speed proposal: Cut out the serde dependency when communicating with steno?

Here's my idea -- I'd like to validate this with additional data, and I'll see if I can sketch out some numbers for potential improvement.

A lot of the structs in nexus/db-model derive serde's Serialize and Deserialize traits, in addition to their family of Diesel traits.

These traits are needed in two spots:

1. https://docs.rs/steno/0.4.0/steno/trait.Action.html returns an https://docs.rs/steno/0.4.0/steno/type.ActionResult.html , which is a serde_json::Value
2. https://docs.rs/steno/0.4.0/steno/struct.ActionContext.html#method.lookup must be able to lookup a https://docs.rs/steno/0.4.0/steno/trait.ActionData.html , which expects Serialize and Deserialize to be implemented.

This "makes sense", in the sense that Steno needs to serialize and deserialize this data. There is a minor quirk here, however -- Steno doesn't really need to parse this information, and forcing these Serialization/Deserialization derives onto all structs that could be stored / retrieved.

For example: if Steno acted on a "byte array" as input / output, we could cut down on a fair bit of monomorphized code (and therefore compile-time), and might be able to use a lighter serialization framework, like https://github.com/dtolnay/miniserde

Start by inspecting the structs in nexus/db-model and their serde Serialize/Deserialize derives. Read the Steno Action and ActionContext lookup interfaces linked in the issue, then gather compile-time or monomorphization data to validate the proposed benefit. Done requires measured evidence and an agreed design for changing the serialization boundary.