Add encoding and bits_per_sample option to save function

[mthrok]

The current release version's "sox_io" backend's save function changes the encoding of the audio file based on the dtype of the Tensor. For example, if the dtype is "float32", then it will be saved as 32bit floating point PCM. This behavior was taken from SciPy's scipy.io.wavefile.write function. However it was pointed out that this is inconvenient for torchaudio users. Because most torchaudio's functionality works on float32 Tensor yet, the common audio formats typically retains only 16 bit, such as 16 bit signed integer PCM.

To resolve the inconvenience while keeping the functionality to support different encodings, this PR

1. Add encoding and bits_per_sample parameters to save function.
2. For non-compressed format (such as "wav"), it defaults to 16-bit signed integer PCM. (This is BC-breaking behavior if users were dumping Tensor object without converting to the matching dtype) The default encoding/bit depth are now determined by dtype, which is not BC-breaking.

Note in #1204, we attempted to solve the issue by adding dtype argument, but after giving more thoughts I concluded that this approach is limited and the design is not intuitive, so we will replace the dtype argument with encoding and bits_per_sample. This will allow other encodings such as mu-law and a-law.
For the detailed behavior of the encoding and bits_per_sample, see the table at the bottom of this description.

Along the way, the implementation of type conversion is updated to use the implementations that libsox provides. So the new implementation of save function yields the same result as sox command.

Table: the provided values and the actual values to be used

• For WAV format without encoding or bits_per_sample option, the encoding configuration is determined by dtype.
• If an invalid value is provided, it raises RuntimeError
• Other formats, like mp3 and vorbis, do no support changing encoding and bits_per_sample, so if users provide some values, they will be ignored with warning.

Provided arguments			Resulting value (if differ)
format	encoding	bits_per_sample	encoding	bits_per_sample
wav, amb	None	None	*	*
		8	PCM_U
		16	PCM_S
		24	PCM_S
		32	PCM_S
	PCM_S	None		32
		16
		24
		32
	PCM_U	None		8
		8
	PCM_F	None		32
		32
	ULAW	None		8
		8
	ALAW	None		8
		8
FLAC	N/A	None		24
		8
		16
		24
Shpere	None	None	PCM_S	32
		8	PCM_S
		16	PCM_S
		24	PCM_S
		32	PCM_S
	PCM_S	None		32
		8
		16
		24
		32
	ULAW	None		8
		8
	ALAW	None		8
		8
		16
		24
		32

[mthrok]

This function implements the mapping from user-provided encoding configuration to the actual encoding configuration for "wav" and "amb" format.

[mthrok]

This function implements the mapping from user-provided encoding configuration to the actual encoding configuration.

[cpuhrsch]

Two general comments:

1. Mapping from -1 to 1 32 bit floating point numbers to 16 bits is lossy in the sense that 16 bits are not enough to store the significant bits of the float. This matters also because this PR changes the default from 32 to 16, which then introduces a loss.
2. When the user went out of their way to request a specific bits_per_sample and a particular format plus encoding doesn't allow that, I think we should throw an error and not a warning, because the request behavior doesn't work. We can still change that if user feedback indicates that they prefer it to just work (and if so, why not just use None to begin with).

[cpuhrsch]

nit: if you want you should be able to use a switch statement for this as well

[cpuhrsch]

nit: you should be able to use the switch statement for these types too, if you want.

[mthrok]

Which type is it? I am getting the following errors; I tried with c10::kFloat and others but got the same result

../../torchaudio/csrc/sox/utils.cpp:219:23: error: switch quantity not an integer
           switch(dtype) {
                       ^
../../torchaudio/csrc/sox/utils.cpp:220:25: error: could not convert ‘torch::kFloat32’ from ‘const c10::ScalarType’ to ‘<type error>’
             case torch::kFloat32:
                         ^~~~~~~~

[cpuhrsch]

You could use the conversion to ScalarType, which will also guarantee that the TypeMeta is indeed a ScalarType (which all your cases seem to assume).