Populate torch_dtype from model to pipeline
Author: B-Step62
Pull request: yes

# What does this PR do?

When constructing a pipeline from a model, it doesn't inherit the `torch_dtype` attribute from the model's dtype. This causes asymmetry of pipeline and model, as the model always inherit the `torch_dtype` when the pipeline is created with `torch_dtype` param. Sometimes it's a bit confusing that the pipeline's `torch_dtype` is `None` (which could mislead the dtype is default one), while the underlying model has different dtype.
Therefore, this PR updates the pipeline construction logic to set `torch_dtype` attribute on pipeline based on model's dtype.


Fixes #28817 


## 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#start-contributing-pull-requests),
      Pull Request section?
- [x] 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.
- [x] 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?
@ArthurZucker @Rocketknight1


Comments:
@ArthurZucker Sorry for my extremely late response...🙇 

Using property to handle model dtype update makes sense. Revised the logic as such so would appreciate if you could take another look. Thanks!

Sorry was off for a week !

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

@ArthurZucker Sorry for bothering you repeated times. I found an issue in this change.

> I found that [TFPretrainedModel](https://github.com/huggingface/transformers/blob/dd1c9052159ae824c8acef7c2552f9fad5ca020a/src/transformers/modeling_tf_utils.py#L1061) doesn't have dtype property so my concern is not the case.

I've just tested a few models and turned out this is no accurate. TFPretrainedModel inherits `dtype` property from [keras.Layer](https://github.com/keras-team/tf-keras/blob/9f64291e2db56f922917185ab8c1d5cd4e962021/tf_keras/engine/base_layer.py#L1173). Its value is not pytorch dtype so returning model dtype as `torch_dtype` property is inaccurate imo.

I think there are a few workaround, 
1. Check the type of `model.dtype` or not, and return nothing if it isn't `torch.dtype`.
2. Check the model is instance of `TFPretrainedModel` and return nothing if so.
3. Rename the property from `torch_dtype` to `dtype`.

I think the first one is most convenient for users, but please let me know your thoughts!

That would be a new feature! Given that before there were no `dtype`. It's not super necessary but yeah we can add a new one

Yeah if the first option sounds good I'm happy to file a follow-up PR now before this change is released. I think it's more proper behavior for `torch_dtype` property (and what its type annotation says:)).