Enhance plotting features

[tsbinns]

Not a direct continuation of GSoC work, but was discussed in this time with @wmvanvliet & @larsoner. Two things were discussed: 1) how plotting of components for multivariate methods should be handled; and 2) adding the ability to plot connectivity spectra.

1) Plotting multivariate components

Since there is now support for returning >1 component for multivariate methods, the question was raised of how these should be handled when plotting. We agreed that in principle, different components could just be treated as distinct connections, and for this I don't see any immediate problems with the visualisation for plot_connectivity_circle() and plot_sensory_connectivity().

However, plot_connectivity_circle() and plot_sensory_connectivity() expect data to have shape (channels, channels), and we are expecting that if the connectivity results contain a freqs. or time dimension, the end user is extracting whatever they're interested in first before plotting. Therefore, simply allowing a new components dimension in the data being plot would deviate from the current implementation, and I could envision some issues where users accidentally pass in data with a freqs or times dimension and things get mislabelled.

An alternative is to leave plot_connectivity_circle() and plot_sensory_connectivity() accepting (channels, channels) data, but having some process within the container classes that if a plotting method is called (which just passes the data to these functions) that if a components dimension is present, the data is unravelled in a way that the different components get added as new channels before being passed to the plotting functions. That's just my initial idea, very open to other suggestions.

Finally this is related, but admittedly an extra point: since plot_connectivity_circle() and plot_sensory_connectivity() expect data to have shape (channels, channels), calling the respective plot methods in anything other than a Connectivity container will raise an error, since other containers will have a e.g., freqs, times, epochs dimension, etc... I just wonder if there's a smoother way to handle this rather than having a method available in the classes that will never work.

2) Plotting connectivity spectra

Something which I (and others) are doing a lot to assess connectivity is plotting the results as a spectrum, but currently there is no built-in method for doing so. I think this would be a very nice QoL improvement. It could work similar to the plot() methods of the Spectrum and TFR classes (depending on whether it's freq.- or time-freq.-domain results). There could be similar parameters for averaging across channels (in our case connections), etc...

I imagine there's a decent amount of the mne.viz backend we could rely on, like we did for the spatial filter/pattern plotting (#208).

Of course, none of this is set in stone; other suggestions are very welcome. I would also be unable to start work on anything of this scale until later in the year, so there's no rush to finalise anything.