Add ViTImageProcessorFast to tests
Author: amyeroberts
Pull request: yes

# What does this PR do?

Accidentally didn't add ViTImageProcessorFast to the test suite when adding the class to the library in #28847 as `fast_image_processor_class` wasn't set in the tester. 

Adds it to the tester and fixes anything needed for tests to pass as well as two additional tests to make sure cross loading between the fast and slow image processors works as expected 

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

Hi @amyeroberts . Could you help me to get some more context regarding the changes in this PR 🙏 ?

From the title and the description, I understand:

- add `ViTImageProcessorFast` to the list so we can test it
- fixes anything needed for tests to pass as well as two additional tests

However, I don't understand why we have the changes below:

- In several files:
```
            elif isinstance(image, np.ndarray):
                h, w = image.shape[:2]
```
Is this because previously we don't test with  `np.ndarray` but now we test in this PR?

- The following two comments seems a bit contradictory to me, but I'm sure I miss some details.
  - `we're feeding in channels_first numpy images for tests, as this is the standard format for numpy images.`
  - `# Numpy images are typically in channels last format`

- why we have special changes in `tests/models/idefics2/test_image_processing_idefics2.py`?

- In `tests/test_image_processing_common.py` , why `channels_first` is changed to `channels_last` ?

Hope I don't ask too much 😅 


@ydshieh Of course! :) Sorry that I didn't make it clear in the PR description. 

> Is this because previously we don't test with np.ndarray but now we test in this PR?

We previously tested with numpy images. However, the numpy images created were in channels first format i.e. (C, H, W). They were essentially numpy versions of images in torch.

When we added the fast image processor, we had to include logic to convert both PIL.Image.Image images and numpy arrays to torch tensors. `torchvision` has:
* [ToTensor](https://pytorch.org/vision/main/generated/torchvision.transforms.ToTensor.html) method which takes numpy and PIL.Image.Image, converts to a torch tensor, then normalizes
* [PILToTensor](https://pytorch.org/vision/main/generated/torchvision.transforms.PILToTensor.html) method, which takes a PIL.Image.Image and converts to a torch tensor but importantly doesn't normalize

We wanted an operation equivalent to `PILToTensor` for numpy arrays (converts to torch tensor but doesn't normalize) as we want to control the normalization factor and whether normalizaton happens (with `do_normalize`), so we added [NumpyToTensor](https://github.com/huggingface/transformers/blob/ec905f3a761bda50cb1d9402eb4e655a1d392732/src/transformers/image_transforms.py#L846)

Within PyTorch transforms, there is the assumption that incoming [numpy arrays are in channels last format](https://github.com/pytorch/vision/blob/bf01bab6125c5f1152e4f336b470399e52a8559d/torchvision/transforms/functional.py#L154). This is reasonable, as this is normally true. 

In order for this transform to now work for the fast image processors, the numpy arrays made for testing needed to be made in channels last, (H, W, C) format. Previously, as the tests had all arrays in channels_first format, the default if/else logic was fine, but now we need to condition on whether the input is a numpy array to get the correct size. 

> The following two comments seems a bit contradictory to me, but I'm sure I miss some details.

They completely are, mistake on my part, I'll update! 

> why we have special changes in tests/models/idefics2/test_image_processing_idefics2.py?

* The `numpify` changes and adding numpy_4_channels test method are because idefics2 has a particular input format. 
* `for image_processing_class in self.image_processor_list:` addition is because for idefics I had to update the numpy_4_channels test method. It's not technically necessary in this PR (happy to remove), and is a change to be made to all image processor tests which override the mixin's original implementation. Otherwise only the slow image processor is ever tested 

> In tests/test_image_processing_common.py , why channels_first is changed to channels_last ?

For the numpy tests, the inputs are now in channels_last format. I could also remove `input_format` completely from the call  and allow this to be inferred, but decided to just update the current values for now