Add Speech AutoModels
# What does this PR do?

<!--
Congratulations! You've made it this far! You're not quite done yet though.

Once merged, your PR is going to appear in the release notes with the title you set, so make sure it's a great title that fully reflects the extent of your awesome contribution.

Then, please replace this with a description of the change and which issue is fixed (if applicable). Please also include relevant motivation and context. List any dependencies (if any) that are required for this change.

Once you're done, someone will review your PR shortly (see the section "Who can review?" below to tag some potential reviewers). They may suggest changes to make the code even better. If no one reviewed your PR after a week has passed, don't hesitate to post a new comment @-mentioning the same persons---sometimes notifications get lost.
-->

<!-- Remove if not applicable -->

This PR adds two auto models for speech:
- one for CTC  (Wav2Vec2, Hubert)
- one for Seq2Seq (SpeechEncoderDecoder, Speech2text)

## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [ ] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/master/CONTRIBUTING.md#start-contributing-pull-requests),
      Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/master/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/master/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?


## Who can review?

Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.

<!-- Your PR will be replied to more quickly if you can figure out the right person to tag with @

 If you know how to use git blame, that is the easiest way, otherwise, here is a rough guide of **who to tag**.
 Please tag fewer than 3 people.

Models:

- albert, bert, xlm: @LysandreJik
- blenderbot, bart, marian, pegasus, encoderdecoder,  t5: @patrickvonplaten, @patil-suraj
- longformer, reformer, transfoxl, xlnet: @patrickvonplaten
- fsmt: @stas00
- funnel: @sgugger
- gpt2: @patrickvonplaten, @LysandreJik
- rag: @patrickvonplaten, @lhoestq
- tensorflow: @LysandreJik

Library:

- benchmarks: @patrickvonplaten
- deepspeed: @stas00
- ray/raytune: @richardliaw, @amogkam
- text generation: @patrickvonplaten
- tokenizers: @n1t0, @LysandreJik
- trainer: @sgugger
- pipelines: @LysandreJik

Documentation: @sgugger

HF projects:

- datasets: [different repo](https://github.com/huggingface/datasets)
- rust tokenizers: [different repo](https://github.com/huggingface/tokenizers)

Examples:

- maintained examples (not research project or legacy): @sgugger, @patil-suraj
- research_projects/bert-loses-patience: @JetRunner
- research_projects/distillation: @VictorSanh

 -->

> yields

I'm not really in favor of aligning pipelines and `AutoModels` 1-to-1 to be honest. IMO there should be a 1-to-1 alignment between model classes `Wav2Vec2For...` and `AutoModelFor...`, but not between `AutoModelFor...` and the pipelines. 

In this case here an auto model class called `AutoModelForAutomaticSpeechRecognition` would be problematic as:

1. It would include models with different API's: `Wav2Vec2ForCTC` does one forward pass and leverages just the `forward()` method whereas `SpeechEncoderDecoder` leverages the `generate()` function. I think we don't want to follow this practice anymore
2. It could lead to problems as soon as there are multiple `Wav2Vec2...` classes that can do ASR

On the other hand, I agreed with @Narsil that for the pipelines it doesn't really make sense to have `AutomaticSpeechRecognitionWithCTC/ WithSeq2Seq / ...` as the target group of the pipelines should have to know the difference betweetn CTC / WithSeq2Seq / ...

More generally, I believe that the `AutoModel...` classes should follow our "barebone"/"no magic"/"easy-to-read code" design whereas the pipelines rather fall in the category "very user-friendly"/"complexity is absorbed at the cost of hard to read/understand code".

So I'm not really in favor of the 1-to-1 alignment I think.

=> Would maybe be a good idea to have a chat about this more generally though! <|||||>I agree with @patrickvonplaten actually.

In my mind, `AutoModelFor...` designates a kind of Head on a particular model, which includes some specific weights and API.
It should have nothing to do with `pipelines` and needs to be completely separated (at least models shouldn't care about pipelines).

On the other hand, for pipelines, relying on `AutoModelFor..` in a 1-1 fashion is tempting, but it does fall apart for `Seq2Seq` (`text-generation`, `translation`, `summarization`) (1-n) and again for `ForCTC` and `ForSpeechSeq2Seq` for instance. (n-1).
For those, it really seems that it just doesn't any sense to keep the 1-1 relationship. But what we do want is a 1-1 relationship
between the `AutoModel` and the widget being displayed and that's possible because there is a sane default for `Seq2Seq` which is `text-generation` (we called it `text2text-generation` but really it's exactly the same API as `text-generation`.

Forcing 1-1 here would mean forcing model developers to care about pipeline and enabling all potential uses for a given head. It would also means that users wouldn't necessarily know which `AutoModelFor..` to use as there would now be aliases. In addition, it would mean we would be forced to unnecessarily add new tasks `automatic-speech-recognition-ctc` and `automatic-speech-recognition-seq2seq`. 
Both are highly undesirable IMHO.

Keeping the current architecture is alright I think.
In case of (n-1) mapping, there needs to be a default task that works (`text-generation` will always work for instance).
And in case of (1-n) mapping, adding switches within the pipeline is OK IMO. As long as there's 1 switch only, and the rest of the pipeline is common it's working fine, but we might want to consider other designs as the pipelines for different `AutoModelFor`  start to differ significantly (like https://github.com/huggingface/transformers/pull/13622?notification_referrer_id=MDE4Ok5vdGlmaWNhdGlvblRocmVhZDI0MzAwMDQwODg6MjA0MzIx#pullrequestreview-758714543). This is a code architecture issue that is very doable IMO.


