Improve `generate` docstring
# What does this PR do?
The generate docstring is not correct, because it has a lot of defaults that read from `model.config` and that is not clearly stated in the method description.

## Before submitting
- [x] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).

## Who can review?

@sgugger @patrickvonplaten I believe this one is for one of you two?


_The documentation is not available anymore as the PR was closed or merged._<|||||>> I think it's best to leave the default as they were (since they are ultimately the defaults for the model config) and put a big warning at the top of the arg section of the docstring stating that all of them will be overridden by the model config. What do you think @patrickvonplaten ?

Things like `model.config.num_beams` change frequently from model to model. Looking at the 'defaults to 1' was very misleading for me.<|||||>Thanks for the feedback here @JoaoLages! I understand the reason behind your PR and am inclined to merge it as is - would like to get some input from @gante here as well though before merging<|||||>This is a tough one. The change (as it is) is possibly good for generate-savvy users but will make it more confusing for most use cases -- all those config values have their own defaults which are in fact almost always used. We would lose that very useful part of the documentation to make this caveat more visible.

In general, we can all agree that defaulting to the config specification is confusing (and a giant source of issues) -- @JoaoLages we are working on a plan to remove them, which is actually the root problem here. This means that documentation changes as a result of this PR will be temporary :) 

Personally, because of the two paragraphs above, I am more inclined toward @sgugger's suggestion -- the most common situation stays clearly documented, and a temporary warning gets added. @JoaoLages WDYT? <|||||>> In general, we can all agree that defaulting to the config specification is confusing (and a giant source of issues) 

Totally agree with this statement!

> Personally, because of the two paragraphs above, I am more inclined toward @sgugger's suggestion -- the most common situation stays clearly documented, and a temporary warning gets added. @JoaoLages WDYT?

The warning would help 👍 <|||||>Awesome, I think we can move forward with it then :) 

One detail -- this warning should go in FLAX's and TF's docstring as well. If it is not asking too much @JoaoLages, can you copy it to the other frameworks as well? 🙏 <|||||>> Awesome, I think we can move forward with it then :)
> 
> One detail -- this warning should go in FLAX's and TF's docstring as well. If it is not asking too much @JoaoLages, can you copy it to the other frameworks as well? 🙏

Actually,[ the warning is already in the docstring](https://github.com/huggingface/transformers/blob/a68454bdfcc14e40e67502722a4d802a2ae26999/src/transformers/generation_utils.py#L910), right? I guess it is not that visible 😅 <|||||>> Thanks for iterating with us!

You were too fast 😂 
I also added the changes for TF and FLAX. Opened another PR https://github.com/huggingface/transformers/pull/18432