[trainer] allow processor instead of tokenizer
Author: sanchit-gandhi
Pull request: yes

# What does this PR do?

Fixes #23222 by allowing the user to pass the argument `processor` to the Trainer and Seq2SeqTrainer (instead of `tokenizer`). 


This is much more intuitive when training multimodal models, as before we were encouraging users to pass:
```python
trainer = Trainer(
    ...
    tokenizer=processor,
    ...
)
```
Which is super confusing. After this PR, users can do:
```python
trainer = Trainer(
    ...
    processor=processor,
    ...
)
```
Which is much more sensible.


The Trainer does three things with the `tokenizer`:
1. Passes it to the data collator with padding:
https://github.com/huggingface/transformers/blob/f4014e75db0190792b3feeccfc5dc5b5f9f0ce7b/src/transformers/trainer.py#L513-L517
2. Gets the model input name:
https://github.com/huggingface/transformers/blob/f4014e75db0190792b3feeccfc5dc5b5f9f0ce7b/src/transformers/trainer.py#L853
3. Saves it during training:
https://github.com/huggingface/transformers/blob/f4014e75db0190792b3feeccfc5dc5b5f9f0ce7b/src/transformers/trainer.py#L3398-L3399

We can do all of these things directly with the processor as well. Therefore, all we have to do is set the following in the init method of the Trainer:
```python
self.tokenizer = processor if processor is not None else tokenizer
```


Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_30864). 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 review @amyeroberts! Note that we are not replacing `tokenizer` with `processor` (this would break all NLP use-cases), but rather allowing multimodal users the option of passing the `processor` directly, which allows it to be saved by the Trainer. Let me know what you think of the proposed design here: https://github.com/huggingface/transformers/pull/30864#discussion_r1603659097

Likewise, we only extract `processor.feature_extractor` or `processor.tokenizer` to do the padding in the data collator -> these are the only two classes with valid padding methods, so there's no surprising behaviour here

@sanchit-gandhi I realise there might be some context missing. There was already a PR which was added to enable this for image_processors #29896 - which was ultimately undone in #30129. 

The ultimate realisation was that adding an argument like `processor` has to be thought out carefully to make sure the behaviour is as clear as possible and behaves as expected for all trainer use cases. One consideration, should we add `image_processor` and `feature_extractor` alongside `processor`? This is definitely clearer, as it disambiguates, but then means we have to handle many objects and their combinations. 

As I mentioned above, this doesn't just affect data collation, but also the objects uploaded to the hub on `push_to_hub` calls, so it's important that the user can pass everything they need to reload their model to the trainer. 

There's an ongoing pull request here #30102, which @NielsRogge has been working on. I agree with his suggestion of a `preprocessor` argument, which means the users can pass any of our processing objects with a single argument. 

I'd missed that PR - thanks for the context @amyeroberts, that's super helpful! Replied directly on the PR: https://github.com/huggingface/transformers/pull/30102#issuecomment-2117074329

This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.

Please note that issues that do not follow the [contributing guidelines](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md) are likely to be ignored.