added memory_d>1 functionality

[NarsimhaChilkuri]

LMUFFT should now be able to handle memory_d > 1, i.e, the input need not be projected down to a scalar before being fed into the delay layer.

[arvoelke]

Awesome! This will be very useful to have. The check inside of LMU that delegates to this implementation can also have the memory_d check removed. Would be good to have a unit test too. Could probably extend one of the ones already in here.

[tbekolay]

Thanks @NarsimhaChilkuri! Can you sign the CAA by adding yourself to this page?

[hunse]

I've got this fixed up and ready to go.

I had to add a has_input_kernel option to allow turning off the input kernel in LMUFFT.delay_layer so that test_layer_vs_cell can pass (otherwise there was a mismatch in the number of weights). This is a feature that I figured we want anyway (a lot of our recent work uses LMUs with no dense encoding layer).

I combined the test that @NarsimhaChilkuri added into our existing test_fft. The main difference is that it tests a few more cases. Otherwise just added a few comments and a changelog entry.

It looks like TravisCI doesn't run when it's an outside contributor branch, so I made a copy of this at origin/multi-dim-memory. The build is running here. (EDIT: That's funny... it wouldn't start a build when I pushed to Nani's branch, but when the build passed on the copy that I pushed to origin, Github was able to identify that a build passed on the same commit and update the check badges below.)

[drasmuss]

Just some minor comments below, looks good overall!

[hunse]

OK, I've addressed your comments @drasmuss.

I also noticed that test_multivariate_lmu was failing on my machine, though it appears unrelated to these changes (it also failed on master for me); upping the tolerances a hair fixed it for me. (I tried explicitly setting all the dtypes to float32, since it seems like it might be some sort of typing issue, but that didn't fix it. 🤷)

[drasmuss]

LGTM