Fix conn_spec multitaper estimator, hanning kernel and complex sxy ou…

[brovelli]

…tput

Multitaper mode (metric coh / plv / sxy)

• _tf_decomp averaged the complex TFR coefficients across DPSS tapers before any spectrum was formed. Tapers are orthogonal, so this cancels most of the signal: |sxy| was ~0.5x the multitaper cross-spectrum and the single-trial coherence was identically 1 without smoothing. _tf_decomp now keeps the taper axis in multitaper mode, (n_epochs, n_chans, n_tapers, n_freqs, n_times), and conn_spec sets tapers_average = mode == 'multitaper' (the line commented out in 4ad29bf).
• _coh averages the cross- and auto-spectra over tapers before taking the ratio (averaging the per-taper coherence gives 1). _plv averages the unit phase vectors over tapers before the modulus.
• A scalar n_cycles is broadcast when mt_bandwidth is an array (used to raise TypeError on len(float)).

Smoothing kernel

• np.hanning(n) has zero end points: sm_times=2 samples produced an all-NaN kernel (NaN output everywhere) and sm_times=3 was a delta (no smoothing). The hanning kernel now uses the n interior points of a (n + 2) window, so sm_times / sm_freqs is the number of non-zero taps.
• __smooth_spectra raises instead of looping forever if the kernel has more dimensions than the spectra.

Cross-spectrum

• The output container used the real default dtype, silently dropping the imaginary part of metric='sxy' (numpy only emits a ComplexWarning). The dtype is promoted to complex64 when needed and the phase convention arg(sxy) = phase(source) - phase(target) is documented.
• Warn when single-trial coh / plv is requested without any smoothing in morlet mode, since the result is identically 1.

Tests: multitaper sxy / coh / plv are checked against a hand-written taper-averaged estimator (rtol 1e-6), the morlet cross-spectrum against w_x * conj(w_y), the hanning kernel for finiteness / positivity, and the power ground truth of test_tf_decomp is recomputed with the taper axis.

Thanks for contributing a pull request!

Please be aware that we are a loose team of volunteers so patience is
necessary. Assistance handling other issues is very welcome. We value
all user contributions, no matter how minor they are. If we are slow to
review, either the pull request needs some benchmarking, tinkering,
convincing, etc. or more likely the reviewers are simply busy. In either
case, we ask for your understanding during the review process.

Again, thanks for contributing!

Reference issue

Example: Fixes #1234.

What does this implement/fix?

Explain your changes.

Additional information

Any additional information you think is important.