Functions in plots module have aes_kwargs, plot_kwargs, stats_kwargs whose keys we need to define. We should define how we want those to behave and document whatever naming conventions we are using to then be able to ensure consistency across plots. Otherwise we'll end up having too many plots and it will no longer be possible to use something intuitive-ish and consistent.

Things I think we have been using quite consistently:

• Full names are preferred over abbreviations or acronyms
• Each visual element has a name which is a valid key in plot_kwargs. This allows users to deactivate/skip any operation the plot does on.
• Keys in aes_kwargs are keys in plot_kwargs. Some might only make sense for plot_kwargs and can be skipped (e.g. "remove_axis") and there can be some exceptions for different visual elements that share the same aesthetic mappings, but this should be done sparsely and only when the different visual elements end up calling the same backend function.
• There aren't really rules or conventions on stats_kwargs so far. Also related to Allow precomputing #40

Open questions:

• what should happen if there are invalid keys?

  I lean towards raising an error.

• what should happen if there are valid keys but that will be ignored?

  I think here the best is probably to ignore them and go ahead, at most print a warning. This would allow for example: plot_dist(..., stats_kwargs={"kde": {"bw": 4}, "hist": {"bins": 20}}) to work and correctly process the kwargs with both kind="kde" and kind="hist" making the switch between different visualizations as painless as possible (as opposed to changing kind and modifying stats_kwargs).

• Should we try to match the keys in stats_kwargs to the key in plot_kwargs where that data is more prominently encoded?