[`AutoDocstring`] Based on inspect parsing of the signature
Author: ArthurZucker
Pull request: yes

# What does this PR do?
- Config stay explicit
- any place that had non explicit (dynamic docstring) gets replaced
- we can leverage inheritance for forward dynamic typing I think




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

> check that we are not compiling, if compiling we don't produce doc probably

Indeed I had some issues with this! When using the `@wraps` decorator in auto_docstring and when compiling, the code would crash with a weird error.
For now I just removed the wraps decorator and it seems to be working.
I'm struggling to catch whether or not we are compiling inside a decorator though for now. 
When testing for `if torch.compiler.is_compiling():` at the very top of the auto_docstring decorator, it's always false, even when running tests like `test_generate_compilation_all_outputs`...

> if this is too slow, we can make sure only the doc-builder actually generates the doc

It's strangely quite fast now! Getting rid of `inspect.getsource` seems to have done the job.
Right now, when profiling `from transformers import *`, I get:
```bash
- total time: 15.581 seconds
- time taken by remaining old docstring decorators: ~2.2 seconds
- time taken by new docstring decorators: ~1.3 seconds
```

On the main branch, I get:
```bash
- total time: 15.581 seconds
- time taken by remaining old docstring decorators: ~3.6 seconds
```

So it might be faster with the new decorators in the end.

Hey @stevhliu ! Would you mind having a look at the new `auto_docstring.md` file? Also this PR changes the way the models docstrings are generated so I thought it could be of interest to you!

>So it might be faster with the new decorators in the end. 
Huge!

@ArthurZucker, could there be some additional work done to prevent this:

```
🚨 `image_seq_length` is part of ImagesKwargs, but not documented. Make sure to add it to the docstring of the function in /code/users/stas/github/transformers-alst-integration/src/transformers/image_processing_utils_fast.py.
...
🚨 `image_seq_length` is part of ImagesKwargs, but not documented. Make sure to add it to the docstring of the function in /code/users/stas/github/transformers-alst-integration/src/transformers/image_processing_utils_fast.py.
🚨 `image_seq_length` is part of ImagesKwargs, but not documented. Make sure to add it to the docstring of the function in /code/users/stas/github/transformers-alst-integration/src/transformers/image_processing_utils_fast.py.
```
one for each gpu.

I'm not using  `image_seq_length` or dealing with images, just doing a post-training of `Qwen/Qwen3-30B-A3B-Instruct-2507` with text.

1. This warning is not actionable for the end user. If it should be actionable by users it should show the trace to pinpoint the offensive caller.
3. If this message is for maintainers of some packages, why is it being shown to end users?
5. Bonus for removing `🚨` - there is enough pollution in the logs multiplied by many gpus to deal with attention pulling unicode. Please don't set a bad precendent for other package managers to copy, we users are drowning in a sea of random messages many packages emit multiplied by the number of gpus.

Apologies if this comment feels frustrated, I'm not sure what else to do other than responding to each of these events as they happen and asking the maintainers to please think about the users when deciding to emit warnings.

Thank you.

Sorry about this, this will be fixed in https://github.com/huggingface/transformers/pull/42054
As this warning is meant for contributor, it will be changed to an error in this PR https://github.com/huggingface/transformers/pull/41635, so contributors won't be able to merge without addressing an undocumented arg issue. 
Hopefully this means you won't see this warning again!

super appreciating this, @yonigozlan! Thank you for fixing both issues!