feat: add support for gradient checkpointing for TimmWrapperModel and TimmWrapperForImageClassification
Author: Yozer
Pull request: yes

# What does this PR do?

This enables gradient checkpointing for timm wrapped models.

## 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).
- [x] Did you write any new necessary tests?


## Who can review?

@qubvel 


Comments:
cc @rwightman 

bump @qubvel @rwightman 
I'm happy to do any fixes if needed. Gradient checkpointing might help others train larger timm models on vram constrained systems like mine.

I think it looks reasonable, might be some corner cases in terms of models that don't support gradient checkpointing asserting and thus throwing an exception, so that might need handling for tests? I feel it's fine for that to happen if someone tries to use the model and it's not supported.

So, in my tests this is used as the set_grad_checkpointing() fn can exist for a model but will assert & throw if not supported

```
    try:
        model.set_grad_checkpointing()
    except:
        # throws if not supported, that's fine
        pass
    else:
        # grad checkpointing supported
```

I am checking if ```set_grad_checkpointing``` exists on underlying timm model but you're right, I can see in timm source code that sometimes set_grad_checkpointing has an assert.

Currently HF will throw if you try to use gradient checkpointing on model that doesn't support it so I would say that it's fine to throw from timm as well.

@rwightman  Do you mean any tests in particular? The one that were run are green, unless you meant a new test case for a model that can assert?

@Yozer I agree that if it throws when using an unsupported feature that's fine, the user will get the message and not try to use it... what I meant for tests is that if there are any tests for the feature, and they assume that based on the 'supports_gradient_checkpointing' flag being true, that grad checkpointing will work ... that won't be the case for timm models so the tests should be setup such that the failure is expected.

@rwightman @qubvel 
Thanks for comments. Could you check the new approach?
1. Logic moved to base class
1. Added test for a model that doesn't support gradient checkpointing (it does the assert thing)
1. I did add try-except with AssertionError so ```supports_gradient_checkpointing``` should truly reflect if timm model supports it or no. I'm slightly afraid of doing enable/disable although I'm doing it very early in ```post_init``` so ```_backward_compatibility_gradient_checkpointing``` should work fine (and the tests for it are green)

Done & done, thanks.
Ready for review @qubvel @rwightman 

@qubvel  @rwightman  bump

@Yozer I think it looks fine from timm perspective, the state toggle should catch the models that don't support it, and it's lightweight enough and I feel it's pretty low risk (it toggles a bool, or bool per stage in some models). @qubvel is final review re Transformers side


**[For maintainers]** Suggested jobs to run (before merge)

run-slow: timm_wrapper

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