Doc: use empty ScalarMappable for colorbars with no associated image.

[anntzer]

This is consistent with the docstring of colorbar(), which explicitly
suggests this approach; this would also later allow deprecating
ColorbarBase, merging it into Colorbar.

PR Summary

PR Checklist

• Has Pytest style unit tests
• Code is Flake 8 compliant
• New features are documented, with examples if plot related
• Documentation is sphinx and numpydoc compliant
• Added an entry to doc/users/next_whats_new/ if major new feature (follow instructions in README.rst there)
• Documented in doc/api/api_changes.rst if API changed in a backward-incompatible way

[jklymak]

I prefer this, but won't merge just yet in case anyone was strongly wedded to ColorbarBase for some reason.

[anntzer]

(note that this was (somewhat) discussed in #3644)

[anntzer]

Added a second commit which replaces cb = fig.colorbar(...); cb.set_label(label) by fig.colorbar(..., label=label) because that seems simpler too.

[timhoffm]

From a usability point of view, creating a colorbar object directly seems simpler. Then again, we usually use factory functions and rarely instantiate objects directly in matplotlib.

From a design perspective, I'm not quite clear who owns the cmap and norm.

• If colormaps would not hold cmap and norm attributes but just query the associated mappable, the approach of this PR makes sense.
• Looking at the code it seems that ColorbarBase actually manages it's own cmap and norm. Colorbar again copies these attributes from the mappable and tries to keep in sync via on_mappable_changed.

In the end, I'm +0.5 because it's already a documented recommendation and it paves the way for deprecating ColorbarBase, and isolated colorbars are a more exotic feature, which is ok to be a bit more cumbersome.

[anntzer]

My plan is to make Colorbar.cmap and Colorbar.norm just properties returning the underlying mappable's cmap and norm, but that'll happen in the big ColorbarBase-deprecating PR.