Generation: deprecate `PreTrainedModel` inheriting from `GenerationMixin` 
Author: gante
Pull request: yes

# What does this PR do?

Step 2 of #32685 - Deprecates the `GenerationMixin` inheritance from `PreTrainedModel`. Instead, models classes with generative capabilities are expected to inherit `GenerationMixin` directly.

This PR: 
- is BC (contrarily to my previous attempt, #33150 😉 )
- has a long deprecation cycle 🤗 BC will be lost in a corner case after removing deprecated code, see caveats section below

## Why?

Currently, we have a *circular logic dependency* between `PreTrainedModel` and `GenerationMixin`:
- `PreTrainedModel` 👈 `GenerationMixin`: `PreTrainedModel` has a `can_generate()` method, which depends on methods that exist in `GenerationMixin`. Depending on the value of `can_generate()`, it may hold a `GenerationConfig` object.
- `GenerationMixin` 👈 `PreTrainedModel`: `GenerationMixin` needed to inspect the type of the model instance, to throw informative exceptions at the user. This was needed because ALL our models could call `generate`, but most of them didn't support it.

This PR sets the deprecation cycle to break this circular dependency:
1. `GenerationMixin` becomes a stand-alone class with no dependencies on `PreTrainedModel`. It is now a proper mixin: it may even be used with other model base classes, if users desire to do so.
2. `PreTrainedModel` doesn't inherit `GenerationMixin`. This means that non-generative models will become less bloated 🤏 💛 

## What else can we improve as a result of this change?

1. [added in this PR] `can_generate()` is no longer dependent on overwrites: if a model is a subclass of `GenerationMixin` then it can generate
2. no need to validate the model class in `generate` -- all `GenerationMixin` subclasses can call `generate`
3. Because of 1., all the changes planned in #32685 become much simpler to implement (`can_generate()` no longer depends on `prepare_inputs_for_generation` -> easier to make structural changes there) 🤗 
4. Perhaps in the future, we can move the `GenerationConfig` instance to `GenerationMixin`, so that non-generative models don't hold a `generation_config` attribute.

## 🚨🚨 caveats 🚨🚨

After removing the deprecated code:
✅ Loading old hub models with custom code, **using our auto classes**, and calling `generate`
❌ Loading old hub models with custom code, **using the custom model code directly**, and calling `generate`. An informative exception will be thrown, suggesting to use our auto classes and sharing instructions on how to solve the problem if that is not possible 🤗 

Comments:
I think the test fetched is failing because I've touched too many files 🙃 

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

Thanks for the PR @gante! I think @ArthurZucker is better suited than I am to review this PR given the changes they do to the modeling code; will defer to him for the initial review

@gante  you can probably try `[test_all] commit message` and see if the fetcher would survive

@ydshieh the new fetcher doesn't complain 🙌 

(@ArthurZucker ping :) Merging this will unblock the migration of `prepare_inputs_for_generate` to `GenerationMixin`)