DFT interface and implementations

[brettviren]

This PR brings a new IDFT interface for performing FFT and two implementations: FFTW3 and Torch. They are thread-safe to call from graph node execute operators.

For the Torch implementation a semaphore may be used to limit number of concurrent calls into Torch. The semaphore itself is a "service" type component as it should be shared by all things that call into torch. Default limit is 1 call. When Torch will run on GPU this may be increased based on available RAM (needs prior understanding of RAM needs and what GPU provides). When Torch runs on CPU note it may use additional threads (up to 4?) beyond what TBB is allowed.

Some tests:

Low level IDFT implementation

# FFTW3 default 
./build/aux/test_idft
# Torch on CPU
./build/aux/test_idft TorchDFT WireCellPytorch
# Torch on GPU
./build/aux/test_idft TorchDFT WireCellPytorch aux/test/test_idft_pytorch.jsonnet

The IDFT interface accepts lowest-common-denominator of pointers to array data.

A higher-level API is provided as functions WireCell::Aux::fwd() and inv() in WireCellAux/DftTools.h. These family of functions take an IDFT::pointer and then provide a data interface based on std::vector or Eigen::Array and handle all the annoying array storage order details.

This high-level API be exercised with:

./build/aux/test_dfttools

This test accepts same command line variants as does test_idft.

This PR should not be breaking to any "core" code but the TorchService configuration interface is reworked a bit to use the new ISemaphore via the new TorchContext mix-in class which is shared by the Pytorch::DFT implementation.

Note, this also removes the unwanted direct dependency on CUDA found in reviewing #131 (thanks!). The rest of the cleanups identified still need to be done....

With this PR, there is no actual code using IDFT outside of the tests. A subsequent PR will start to replace the hard-wired use of DFT functions from Waveform and Array with their IDFT equivalent.

Future work may be expected which will implement cuFFT and/or ZIO based IDFT backends.

[brettviren]

I snuck in a few improvements to this PR but I'll stop now. When you get a chance @HaiwangYu please review.

Next I'll replace existing hard-wired DFTs with IDFT and that will go to a branch on top of idft with a new PR.

[brettviren]

I'll close this PR in favor of PR #136 on branch idft-use. It is a super-set of this one which also includes replacing the hard-wired dft()/idft() calls with ones that go through an IDFT. It's almost ready and I think having two separate PRs to merge at this point will be more disruptive than helpful.