Add a unified messaging system for tool options

[henryksloan]

#283 completed all of #184 except for:

A unified approach to routing options changes to the backend, and the state of those options back to the frontend

Each tool should probably have an associated options struct on the frontend. Each tool option widget should probably have an onChange or analogous callback that updates the struct and then sends it to the backend. Updates to a tool's options within the backend should probably send a Response to the frontend, allowing it to update the tool's options struct. Persisting the option widgets should probably occur at this response handling step (see zoom and rotate).

The main question is how to associate each widget with a field in the struct. The easiest thing would probably be to somehow identify the field within the option object (e.g. NumberOption { ... option: "shape_type.Polygon.new_value" }), or possibly a choice between this approach and a custom callback.

Buttons should most likely be implemented by associating a string with the button, that will be translated to a variant of a new struct like OptionButtonMessage. It would be nice to have a button messages enum for each tool.