[processor] Add 'model input names' property
# What does this PR do?

Adds the `model_input_names` property to the processor class. Related to #20058.

## Who can review?

Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.

<!-- Your PR will be replied to more quickly if you can figure out the right person to tag with @

 If you know how to use git blame, that is the easiest way, otherwise, here is a rough guide of **who to tag**.
 Please tag fewer than 3 people.

Models:

- albert, bert, xlm: @LysandreJik
- blenderbot, bart, marian, pegasus, encoderdecoder,  t5: @patrickvonplaten, @patil-suraj
- longformer, reformer, transfoxl, xlnet: @patrickvonplaten
- fsmt: @stas00
- funnel: @sgugger
- gpt2: @patrickvonplaten, @LysandreJik
- rag: @patrickvonplaten, @lhoestq
- tensorflow: @LysandreJik

Library:

- benchmarks: @patrickvonplaten
- deepspeed: @stas00
- ray/raytune: @richardliaw, @amogkam
- text generation: @patrickvonplaten
- tokenizers: @n1t0, @LysandreJik
- trainer: @sgugger
- pipelines: @LysandreJik

Documentation: @sgugger

HF projects:

- datasets: [different repo](https://github.com/huggingface/datasets)
- rust tokenizers: [different repo](https://github.com/huggingface/tokenizers)

Examples:

- maintained examples (not research project or legacy): @sgugger, @patil-suraj
- research_projects/bert-loses-patience: @JetRunner
- research_projects/distillation: @VictorSanh

 -->

Currently, I've only applied the change to the Wav2Vec2 Processor - once we're happy with the design I'll copy it to all other processor classes (both audio and vision). This should make the preliminary review much easier!<|||||>The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_20117). All of your documentation changes will be reflected on that endpoint.<|||||>Thanks for the review!

> Just one thing: should this be overriden for CLIP models and the like that combine the inputs of the tokenizer and feature extractor?

That's a very good point. Perhaps we can add a generic property method to `ProcessorMixin` that returns the `model_input_names` for the first attribute (feature extractor), and override it for the models that combine the inputs of the tokenizer and feature extractor?

Or, we can add the property method to **each individual** processor class, tailored to return the expected inputs for the given model (as is currently done with Wav2Vec2Processor, and modified accordingly for CLIP etc).<|||||>Great point @sgugger! Have quickly cleaned-up the PR to try and remove any ad-hocery in the tests:

- Single modality models: assert that the model input names of the processor and feature extractor match
- Multi modal models: assert that the model input names of the processor match the keys of the inputs dict<|||||>Very much agreed - if we implement a common tester for the processor this all collapses into one / two tests max. Will leave this for a follow-up PR as it's quite a significant refactor!<|||||>The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_20117). All of your documentation changes will be reflected on that endpoint.<|||||>The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_20117). All of your documentation changes will be reflected on that endpoint.<|||||>The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_20117). All of your documentation changes will be reflected on that endpoint.