New Wav2Vec2 padding has slightly backward breaking changes
The PR: https://github.com/huggingface/transformers/pull/13650 introduced some quite tricky backwards breaking changes that we should try to fix. 

The problem is the following: A user might directly use `feature_extractor.pad(...)` instead of `feature_extractor(...)` to just pad already preprocessed inputs in, *e.g.* a data collator.

The following code correctly returned `torch.float32` before merging the PR while the new PR returns `torch.float64` which is slighly breaking and can lead to errors in current fine-tuning Wav2Vec2 scripts:

```python
from transformers import Wav2Vec2FeatureExtractor
import numpy as np

extractor = Wav2Vec2FeatureExtractor.from_pretrained("facebook/wav2vec2-base-960h")

rand_input = np.ones((100,), dtype=np.float64)
out = extractor.pad([{"input_values": rand_input}], return_tensors="pt")

print(out.dtype) # <- this should be `torch.float32`
```

Here is a colab showing how the "old" version works correctly: https://colab.research.google.com/drive/10TlRWvwKx34UORmYdCFAyMWKUU3OtPRf?usp=sharing

Here is a colab showing how the "new" version works incorrectly: 
https://colab.research.google.com/drive/1cXGuG4Rnypmivdm-vdE-61BA1f4hC4e8?usp=sharing
@anton-l - could you maybe look into it? :-) It's quite a tricky backwards compatible bug and we should have had tests to catch this problem. Would be great if you could try to open a PR to fix it :-)<|||||>Good catch! This is due to how pytorch converts float numpy arrays vs python lists:

* torch.float32 for python lists by default: `torch.tensor([1.2, 2.3]).dtype  #  torch.float32`
* `np.array([1.2, 2.3]).dtype  # np.float64` 
* source dtype for numpy arrays: `torch.tensor(np.array([1.2, 2.3]).dtype  #  torch.float64`