[WIP] Replace FFTW with FFTA.jl as default FFT backend

[asinghvi17]

Summary

Replace FFTW (GPL licensed) with FFTA (MIT). This still needs a bunch of work and probably a new release of FFTA to bring it up to speed with AbstractFFTs.jl and what we need here, so we can remove hacks in this package

Changes

• New src/fft/FFTBackend.jl: Abstract FFT backend interface
• New src/fft/FFTAImpl.jl: FFTA backend implementation
• New ext/FFTWExt.jl: FFTW package extension
• Updated source files to use FFTBackend instead of direct FFTW imports

Usage

using DSP          # Uses FFTABackend by default
using FFTW         # Automatically switches to FFTWBackend for better Float64 performance

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 45.19231% with 57 lines in your changes missing coverage. Please review.
✅ Project coverage is 96.73%. Comparing base (77c99a2) to head (9bdd74b).

Files with missing lines	Patch %	Lines
src/fft/FFTAImpl.jl	6.12%	46 Missing ⚠️
src/fft/FFTBackend.jl	68.42%	6 Missing ⚠️
ext/FFTWExt.jl	72.22%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #653      +/-   ##
==========================================
- Coverage   98.13%   96.73%   -1.41%     
==========================================
  Files          19       20       +1     
  Lines        3279     3249      -30     
==========================================
- Hits         3218     3143      -75     
- Misses         61      106      +45     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[baggepinnen]

This is not quite true, the in-place version is mul! on the corresponding plan object

[wheeheee]

The idea for this PR isn't bad (I presume some kind of FFTA -> FFTW syntax translation package cum trampoline), but IMO that's more general than should be in this package.

So, I believe it's better if you develop it as a standalone package, maybe ask JuliaMath if they want something like this. If it gets mature enough we can just switch to it later on.

[asinghvi17]

Yeah, that's probably the better approach. I started this before I realized the API mismatch 😅

[ViralBShah]

It would be good to get @stevengj's thoughts on this. I think a lot of people like having non-GPL dependencies as the default, but we should only do it if those are the best. Otherwise, we may want a more flexible system to pick different defaults.

[stevengj]

It's perfectly reasonable to have a pluggable backend, and really the whole AbstractFFTs.jl structure needs to be re-done so that this can be done in a composable way (JuliaMath/AbstractFFTs.jl#32)

However, as a default method, I currently have serious accuracy concerns about FFTA.jl: JuliaMath/FFTA.jl#118 (aside from performance questions).