Deprecate multi-arg and tuple nextfastfft

[martinholters]

Closes #291. I agree with the assessment therein and add that the remaining method is the only one documented.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 97.84%. Comparing base (3ed388e) to head (196868a).
Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #578      +/-   ##
==========================================
- Coverage   97.84%   97.84%   -0.01%     
==========================================
  Files          19       19              
  Lines        3252     3250       -2     
==========================================
- Hits         3182     3180       -2     
  Misses         70       70              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[wheeheee]

Looks fine, unless somewhere down the line there's a more optimal padding heuristic that doesn't generalize so well to nD?

[martinholters]

Ah, that's a valid point, it already shows for n=2:

julia> @btime fft($(rand(            91 , 2^16)));
  121.739 ms (8 allocations: 182.00 MiB)

julia> @btime fft($(rand(nextfastfft(91), 2^16)));
  359.419 ms (8 allocations: 192.00 MiB)

while

julia> @btime fft($(rand(            91 )));
  3.718 μs (6 allocations: 3.48 KiB)

julia> @btime fft($(rand(nextfastfft(91))));
  3.238 μs (6 allocations: 3.48 KiB)

(BTW, I have no clue why the 2d-case is that bad.)

But even if we decide that a proper nextfastfft(ns::Tuple) is worth doing (and I have no idea what it should look like), we don't know whether any current uses outside DSP.jl actually then do an nD-FFT or just multiple 1D-FFTs of different sizes -- unlikely, but possible -- after calling nextfastfft. So changing this might come as a surprise. Unless we go through a deprecation cycle first, that is, and then re-introduce it with proper docs.

[wheeheee]

I don't see any usage of the Tuple version from a JuliaHub search, excluding DSP.jl's internal consumption, so concerning registered packages there likely isn't any trouble either way.

[martinholters]

Ok, so instead of deprecating, we could also document the mutli-arg and/or tuple method and point out that in the future, the result might be optimized towards nD-FFT and not just be determined point-wise. I'd be fine with both. I still tend to prefer the current PR, but just because the work's already been done. So if anyone opens a PR with the docs change, I'm happy to close this one, otherwise I'll go ahead and merge in a few days.

[martinholters]

Closing in favor of #580.