fix: [whisper] don't overwrite GenerationConfig's `return_timestamps` when `return_timestamps` is not passed to `generate` function
Author: hrl
Pull request: yes
Labels: name: Generation

name: Audio

# What does this PR do?

When [`WhisperGenerationMixin.generate`](https://github.com/huggingface/transformers/blob/ab0f050b42d903f34d6eb97f3f8c0c07f0517ad2/src/transformers/models/whisper/generation_whisper.py#L509) called without `return_timestamps`, GenerationConfig's `return_timestamps` will be overwritten to `None`.

It's okay if we can control `generate`'s arguments. But in some particular case, for example, in [`Trainer.evaluation_loop`](https://github.com/huggingface/transformers/blob/ab0f050b42d903f34d6eb97f3f8c0c07f0517ad2/src/transformers/trainer.py#L3757), then in [`Seq2SeqTrainer.prediction_step`](https://github.com/huggingface/transformers/blob/ab0f050b42d903f34d6eb97f3f8c0c07f0517ad2/src/transformers/trainer_seq2seq.py#L310), there is no way to pass `gen_kwargs` to `generate` function. (#19777)   
Which makes it impossible to generate with timestamps to calculate generative metrics when training.

This PR fixes this case by initializing `return_timestamps` to GenerationConfig's value.

## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#create-a-pull-request),
      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/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/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.

@patrickvonplaten @sanchit-gandhi


Comments:
Possibly cc @gante as it relates to generation 

cc @kamilakesbi 

@hrl did you have time to iterate on this ? thank you! 

> @hrl did you have time to iterate on this ? thank you!

@kamilakesbi conflicts resolved.

> Could you add a test?
> I'd just like to confirm this behaviour is consistent with the rest of the generation API cc @gante

@amyeroberts I'm not familiar with the rest of the generation API. Should I write a test for this?

The behavior will be different only when `GenerationConfig.return_timestamps == True` and `return_timestamps` is not passed to `generate`.


> @amyeroberts I'm not familiar with the rest of the generation API. Should I write a test for this?

Oh, no worries, this was a question for @gante, our generate king and who knows all the ins-and-outs best :) 

Gentle ping @gante 

(@amyeroberts @kamilakesbi the root cause for the issue behind this PR is that Whisper's `generate` breaks a few assumptions present in the global `generate`, such as how the generation config and the `generate` kwargs interact with each other. Some of our tools, like `Trainer`, are built with the general case in mind -- I will try to nudge Whisper towards the general case whenever I see the opportunity 🤗 )