[Proposal] Create vis_options plugin for creating modular visualization editing interfaces

[joshuarrrr]

Many user-specified visualization options are common and repeated across a variety of different visualization types. Today, authors of new visualization types need to 1. define the user configurable options in some sort of visualization config definition; 2. build out UI components to map to those configurations; 3. make sure the chart type rendering function correctly implements those configurations in the render layer.

Instead, we should think of visualization options as modular, composable building blocks which can be used as the major ingredients in the definition of a visualization type. Each chart option definition would be composed of:

1. A standard configuration representation (what gets stored in a saved object, passed to a renderer)
2. A standard input UI component (for use in a visualization editor)
3. A rendering implementation that maps the config to a partial Vega-Lite spec (in the future, if more than one visualization rendering engines are supported, there may be multiple rendering implementations)
4. Default values and bounds based on visualization best practices and resolved visualization styles

This approach would have several benefits:

1. More consistent look, feel, and behavior of visualization option inputs across different visualization editors
2. More consistent styling and controls across visualization types
3. Faster and easier implementation of new visualization types

Potential tasks:

• Migrate existing option UI components from charts plugin
• Group and abstract collections of options that can be set together