Fix some FastSpeechConformer2 failing tests
Author: ylacombe
Pull request: yes

# What does this PR do?

- Fixes #31270 that happened because of the wrong text-to-waveform mapping
- Fixes mono-gpu failing tests (cf [here](https://github.com/huggingface/transformers/actions/runs/9823944203/job/27122464080))

FastSpeechConformer2 also suffers from faililng `test_multi_gpu_data_parallel_forward`, I'll address this later, don't hesitate to share if you think of a reason for this bug!

cc @amyeroberts and @ydshieh  

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_31842). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

Hey @amyeroberts, thanks for reviewing!

Turns out the proposed solution to fix https://github.com/huggingface/transformers/issues/31270 isn't the right one.
- **What it was supposed to fix:** [`fastspeech2_conformer` is located in 2 `MODEL_FOR_TEXT_TO_...` classes.](https://github.com/huggingface/transformers/blob/4c2538b863d8949a98d6b8dc1dea9ed4cf96a5df/src/transformers/models/auto/modeling_auto.py#L1217-L1236) When using the model with `pipelines`, it tries to load the model class indicated in `MODEL_FOR_TEXT_TO_WAVEFORM_MAPPING_NAMES`, whereas it should load the other model class.
- My solution consisted in modifying the mapping of `MODEL_FOR_TEXT_TO_WAVEFORM_MAPPING_NAMES` to use `fastspeech2_conformer_with_hifigan` instead of `fastspeech2_conformer`. However, in that case, we also need to add `fastspeech2_conformer_with_hifigan` in `MODEL_NAMES_MAPPING` and `CONFIG_MAPPING_NAMES`, which in turns forces us to add  `FastSpeech2ConformerWithHifiGan` to `index.md`.


To be totally rigorous, the initial error comes from how the pipeline determine which class it should use:
https://github.com/huggingface/transformers/blob/99c0e5533553d83e02bb327a487e331d5afd9739/src/transformers/pipelines/base.py#L267-L290
Here you can see that it iterates over a tuple. In our case, it's made of (`AutoModelForTextToWaveform`, `AutoModelForTextToSpectrogram`, `FastSpeech2ConformerModel`).

If we zoom in, we see that even if there's an error, the pipeline should continue to iterate over the tuple:
https://github.com/huggingface/transformers/blob/99c0e5533553d83e02bb327a487e331d5afd9739/src/transformers/pipelines/base.py#L282-L290

Turns out, it doesn't continue. Any idea how I can solve this @amyeroberts ?


@ylacombe You can add a model to [MODEL_NAMES_TO_IGNORE](https://github.com/huggingface/transformers/blob/aec1ca3a588bc6c65f7886e3d3eaa74901a6356f/utils/check_table.py#L176) if you don't want it to be added to the index.md. 

Changing the mapping I think is OK in general, although technically this could be a breaking change. For example, models which have  
`"fastspeech2_conformer"` as the model type could previously load a `FastSpeech2ConformerWithHifiGan` model, however I'm assuming this would be technically incorrect and error as shown in the issue, so not really a "breaking change".

We should check if I saved a checkpoint out for a `"fastspeech2_conformer_with_hifigan"` model, it will correctly load a feature extractor. And is the model type is correctly saved as `"fastspeech2_conformer_with_hifigan"`

Just to make sure I've understood the desired behaviour, you want the checkpoint espnet/fastspeech2_conformer to load a `FastSpeech2ConformerModel` and not a `FastSpeech2ConformerWithHifiGan` model? 

> If we zoom in, we see that even if there's an error, the pipeline should continue to iterate over the tuple:

Not quite, it should only continue if there's an `OSError` or a `ValueError`. What's triggered is an `AttributeError`

Thanks @amyeroberts, it's really clear, I've updated the lists as you've suggested.

I'm still a bit confused as to why the current quality check fails: https://app.circleci.com/pipelines/github/huggingface/transformers/99400/workflows/98b29d92-00c4-4ff2-b6bd-c67f12255b50/jobs/1321926

When doing `make fix-copies`, no new lines are added, and the only difference is in the number of spaces:

Before:

```
|                        [ALBERT](model_doc/albert)                        |       ✅        |         ✅         |      ✅      |
```
After:
```
|                           [ALBERT](model_doc/albert)                            |       ✅        |         ✅         |      ✅      |
```

@ylacombe I have no idea re fix-copies, unless it was modified manually? If you run `make fix-copies` and push the changes, do the tests still fail remotely?