ENH: add support for passing arbitrary kwargs for axes.contours in annotate_contour

[neutrinoceros]

PR Summary

incidentally fix #4459

[neutrinoceros]

I'm going to prioritise #4475 over this.

[neutrinoceros]

rebased to resolve merge conflicts.
To be explicit, this is ready for review :)

[brittonsmith]

Is there an advantage to replacing the plot_args dict with **kwargs? My impression is that we had moved away from **kwargs toward dicts as a means of keeping keywords grouped according to destination. For example, in this same function, we have a text_args dict. Unless there is a specific benefit, I'm not sure I support this change.

[neutrinoceros]

My impression is that we had moved away from **kwargs toward dicts as a means of keeping keywords grouped according to destination. For example, in this same function, we have a text_args dict. Unless there is a specific benefit, I'm not sure I support this change.

This strategy still has value but it's not necessary to have all arguments be passed through dictionaries: (n-1) dictionaries arguments (with n, the number of destinations) is sufficient ! My point (and proposed change) is that we can still leverage **kwargs (which is very idiomatic in matplotlib) for the most common destination without limiting design space.

[brittonsmith]

The minor benefit I see from keeping text_args and plot_args is that it is clear where the keywords are being shipped off to. Other than this, this change feels like mostly a lateral move with the downside of breaking backward compatibility. I think this is the point where it is probably worth getting other opinions. I'd rather not see API changes made or blocked based on individual opinions, but I am happy to defer to a majority. @matthewturk and I have not discussed this (although maybe you have with him), so he should have a fresh opinion.

[neutrinoceros]

The way I see it there are three options to choose from:

1. keep the API from main (no support for **kwargs)
2. support **kwargs and deprecate plot_args (this is the current state of the branch)
3. support both APIs (same as this branch, but without the deprecation)

I don't think any option is ideal: there are precedents to support options 1. and 2., and I have a personal preference to not keep support for more than one API for ever, but maybe option 3. is probably an agreeable middle ground ?