Config: warning when saving generation kwargs in the model config
Author: gante
Pull request: yes

# What does this PR do?

## Context

`generate` is ideally controlled by a `GenerationConfig`. However, to remain retrocompatible, a `PretrainedConfig` may control `generate` in the following conditions:
1. `generate` does not receive a `generation_config` argument; AND
2. `model.generation_config._from_model_config is True`, which means the user never manually created a `GenerationConfig`; AND
3. the user has not modified `model.generation_config` since it was created, which (together with 2.) means that `model.generation_config` holds a copy of the generation parameterization in `model.config` at init time; AND 
4. [added in this PR] the model config holds non-default generation kwargs, which means there is some intent to control generation through the model config

Having the legacy behavior active essentially means there are two places to control generation, which has been causing some GH issues. We can't get rid of it (we would have to submit PRs to thousands of models), but we can be more persuasive in slowly shifting new models entirely towards the `GenerationConfig`. This should help with documentation, ease of use across tasks such as fine-tuning modern models, as well as reducing the number of occurrences of the legacy behavior warning (see [1:03 in this video](https://twitter.com/reach_vb/status/1736471172970086792) -- many @TheBloke models suffer from it, as `max_length` is set in the model config and not in the generation config).

## This PR

This PR adds:
1. Clause 4. in the context list above, to avoid showing the warning when there was no intent of controlling `generate` through `model.config`
2. Two future deprecation warnings in the following legacy-triggering situations:
  a. When saving a `PretrainedConfig` with non-default generation attributes, which demonstrates an intent to control `generate` through it. Users are nudged towards using `GenerationConfig` instead;
  b. When saving a model where `model.generation_config` is built from `model.config`, but `model.config`'s generation attributes have been modified since the creation of `model.generation_config` (i.e. the two hold different `generate` parameterization). Users are nudged towards creating a brand new `GenerationConfig` instead.

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

@amyeroberts PR comments addressed!

@amyeroberts @ArthurZucker What do you think would be a sensible deprecation time frame? I do agree it can become a sensible exception: raising an exception at `save_pretrained` corresponds to breaking the training runs (the model artifact is only stored after these lines) ⚠️ Perhaps 6 minor versions, instead of the standard 2?

(I wouldn't want to leave it to `v5`, as there would be little incentive for the users to do something about it)

@gante Definitely not until v5 💀  I'd say 4? I don't feel strongly, so happy to go with what you or @ArthurZucker think is best.  

Bumped to 4 minor versions 👍 (i.e. set to deprecate in v4.41)

Sorry saw this a bit late, LGTM