Save `Processor`
Author: ydshieh
Pull request: yes

# What does this PR do?

Save `Processor`.

Comments:
The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_27761). All of your documentation changes will be reflected on that endpoint.

Thanks for giving your opinion 👍  Ready for the review.

There is no test specific for this new feature so far, as we don't have a common processor test file yet. But the current set of tests can detect issues if any.

There is #27720 however.

@ydshieh Thanks for all the work in this PR! 

I'm wondering if we should hold off on saving processor configs out until we refactor the processors to standardise their inputs and outputs. Otherwise we're going to introduce config files and values which we'll have to maintain backward compatibility with cc @molbap 

Would not merging be blocking anything else? 

Good point! It makes a lot of sense, thank you.

#27718 is waiting this PR I believe.

But let me double check:

> refactor the processors to standardise their inputs and outputs

this sounds to me that we are talking about the arguments in a process's `call` method, in particular `text`, `images` etc (the most important ones). However, saving a config file for a processor only saves `__init__` argument, which is not about input/outpu of processor.

Do I miss anything in your message?

@ydshieh Nope - you're completely right - I forgot it's just the processing classes passed to the processor init. 

Part of the future plan is to potentially have modality specific processors e.g. TextImageProcessor to make it more explicit in e.g. pipelines how inputs and outputs should be handled. I'm guessing this won't be an issue here as the e.g. TextImageProcessor acts more like the Auto classes and can use model specific configs to construct themselves?

If we ever introduce `TextImageProcessor` and/or `TextAudioProcessor` etc, I think they are not exactly same as auto classes but instead an abstraction one level above the explicit classes.

- auto: allow to load any checkpoint: `AutoProcessor.from_pretrained(".....")` should work
- explicit class: only allow to load a checkpoint of a specific model type: `CLIPProcessor.from_pretrained(".....")` should work for checkpoint of a CLIP processor but not others (well, we allow it by give warnings)
- `TextImageProcessor`: they should not to be used as `TextImageProcessor.from_pretrained()`, just like we don't use `ProcessorMixin.from_pretrained()`

------------------

But back to the question

>  I'm guessing this won't be an issue here and can use model specific configs to construct themselves

If we ever allow to use `TextImageProcessor.from_pretrained()` (which I am against) and behave like `AutoProcessor`, then under the hood it still try to find the actual type (class) and use that type + the config file to construct  the object of that type.

**So I don't see any issue regarding such `TextImageProcessor` with the change in this PR 🤗** 

Well, after a 2nd though, I think it's better to add the processor common testing for this PR to avoid the situation where we won't be able to fix in the future once the new processor config file being saved have some issues.

change this to draft for now.

The PR is ready for review. Regarding [the comment](https://github.com/huggingface/transformers/pull/27761#discussion_r1448533919), see [my response](https://github.com/huggingface/transformers/pull/27761#discussion_r1448552231).

For [we only call the hub once](https://github.com/huggingface/transformers/pull/27761#discussion_r1448620683), as we don't have such tests for image processor/feature extractor/processor currently, and it's not critical, I think it's better to deal with them in a follow up PR.

(In fact, I don't know if it is true that we can have only one call to the Hub for processor - considering processor have 2 components)

I guess we are all good and I can merge? 

Still think we can simplify the way you handle kwargs, but alright otherwise