add autograd to biquad filters

[yoyololicon]

implement feature requested in #1375

Affected functions:

• biquad
• band_biquad
• bass_biquad
• allpass_biquad
• highpass_biquad
• lowpass_biquad
• bandpass_biquad
• bandreject_biquad
• equalizer_biquad

[cpuhrsch]

Why the call to squeeze here each time?

[yoyololicon]

Oh thanks, I found that it's not necessary, will remove these lines.
My initial idea is to make sure that arguments pass to biquad in return statement are scalar tensors, so it can be jittable.
But actually, if user pass unit length tensor (like torch.Tensor([1.])) as input and use torch.jit.script, it will throw error in the first place before calling biquad.

[cpuhrsch]

Here you could also use torch.as_tensor and construct the array right away.

>>> torch.as_tensor([4, torch.tensor(2), 3], dtype=torch.float)
tensor([4., 2., 3.])

[yoyololicon]

Have tried this approach but it didn't pass gradcheck so roll back to use concatenation.

[cpuhrsch]

Looks fine to me! @mthrok can you take another final look?

[mthrok]

The change looks good and this is a very cool change. Thanks @yoyololicon

Couple of thoughts (for follow-up)

1. Should we mention the support of autograd in documentation for the functions that are tested?
2. Can we introduce a helper method for Autograd test that handles dtype, device and requires_grad property, so that each test method looks simpler. Example -> https://github.com/pytorch/audio/blob/e4a0bd2ceb6c80ec90194ce519bbd9589926034b/test/torchaudio_unittest/transforms/autograd_test_impl.py
3. What about the second order gradient? i.e. gradgradcheck

[yoyololicon]

2. Can we introduce a helper method for Autograd test that handles dtype, device and requires_grad property, so that each test method looks simpler. Example -> https://github.com/pytorch/audio/blob/e4a0bd2ceb6c80ec90194ce519bbd9589926034b/test/torchaudio_unittest/transforms/autograd_test_impl.py

Looks good, will work on it later if I have time.

3. What about the second order gradient? i.e. gradgradcheck

Current implementation can't support higher order derivative (still use inplace operation internally).
I'm not sure whether there is a need for it, personally a first order derivative is sufficient.