Generation: deprecate PreTrainedModel inheriting from GenerationMixin

[gante]

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, Generation: PreTrainedModel no longer inherits GenerationMixin 🚨 🚨  #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 tracker: move prepare_inputs_for_generation into the generation mixin 🧹  #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 🤗

[gante]

Note: This function was touched to avoid a circular import (the from ..models.auto imports)

[gante]

This warning should only appear in the case that is not BC after removing the GenerationMixin inheritance in PreTrainedModel. See caveats section of the PR header.

[gante]

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

[HuggingFaceDocBuilderDev]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[LysandreJik]

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

[ydshieh]

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

[gante]

@ydshieh the new fetcher doesn't complain 🙌

[ArthurZucker]

Cool! Thanks for this chore update!

[ArthurZucker]

if it does not inherit from generationMixin should we rais an error?

[gante]

Not quite, we have the time series models that overwrite generate (and, prior to this change, can_generate() returned True for them)

[gante]

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

[ArthurZucker]

Sorry for the delay, thanks for fixing!