Add return_complex to F.spectrogram and T.Spectrogram

[mthrok]

This PR adds return_complex argument to

• F.spectrogram
• T.Spectrogram
• T.MelSpectrogram
  Note: Since MelSpectrogram performs scale conversion on real valued power spectrogram (R->R function), return_complex is not added to it.

TODO:

• Add autograd test for return_complex=True
• Add TorchScript test for return_complex=True
• Add librosa test for return_complex=True

Part of #1337
Previous discussion #1009

[anjali411]

I'd suggest adding a warning that Spectrogram now supports native complex tensors. Currently we return pseudo complex tensors (..., 2) by default, but that will change in the future and return_complex would be set to True by default ... something along those lines

[mthrok]

I like the idea but in domain libraries, it is agreed to not mention the migration plan or future plan in docstring. (even though there are exceptions that I made, when this rule was made)

@cpuhrsch brought this up and this is meant to follow the same approach as PyTorch. But if PyTorch also mentions future plan in docstring, please point us to it.

The general idea behind of it is, this kind of direction should better live in release note or issue.

[gchanan]

We try to always mention the new path. To me, the definition of deprecation is two parts:

1. this isn't recommended anymore
2. this is what you should do instead

you could, I guess, but those in the release notes by why make it more difficult for your users?

[mthrok]

Oh sorry I misread the comment by @anjali411 as adding the suggested sentence to docstring. Yes, there is nothing goes against on adding it to warning.

[mthrok]

I will make a follow up PR.

[anjali411]

Thanks Moto! This looks a great overall. Consider adding a warning to alert the users about this migration, and also a serialization test.