Fix donut image processor
# What does this PR do?

This PR addresses failing integration tests for the Donut image processor which involves four main changes: 

* Resolve bug where `size` wasn't passed to `do_align_axis`
* Remove a bug in the `get_resize_output_image_size` function which wouldn't take account of `max_size` ([inherited from previous resize without fixing](https://github.com/huggingface/transformers/blob/7586a1a367f5974e099e1be2fa8a751aa766179f/src/transformers/image_utils.py#L451))
* Update logic for getting output size in `thumbnail` method - ensuring the image dimensions are never increased. 
* Update test values to reflect changes in resizing logic for thumbnail creation - see notes below. 

### Changing resizing logic for `thumbnail` method

The DonutFeatueExtractor used the [Pillow thumbnail functionality](https://github.com/huggingface/transformers/blob/6cc06d17394f5715cdf2d13a1ef7680bedaee9e2/src/transformers/models/donut/feature_extraction_donut.py#LL109C18-L109C18) to resize images which was [replaced with reusing `resize`](https://github.com/huggingface/transformers/blob/bf9a5882a7125a6050aaad0f52257f07df062d6a/src/transformers/models/donut/image_processing_donut.py#L226) in the image_transforms library. This was done primarily as `image.thumbnail` modifies in place and uses [Pillow's resize](https://github.com/python-pillow/Pillow/blob/1e28c8cffd8492af6bf5df2045e7ffe08b124033/src/PIL/Image.py#LL2538C13-L2538C13) with some additional logic for calculating the output size. Unlike `resize` which will resize an image to the requested `(height, width)`, `thumbnail` will produce an image which is no larger than the original image or requested size i.e. it will scale down an image preserving the aspect ratio c.f. [Pillow docs](https://pillow.readthedocs.io/en/stable/reference/Image.html#PIL.Image.Image.thumbnail). 

This is a similar behaviour to torchvision when resizing:
* the shortest image edge is resized to `size` (int for torchvision, `min(requested_heigh, requsted_width)` for Pillow)
* the other edge is resized to preserve the aspect ratio
* if the longest edge > `max_size`, the longest edge is resized to `max_size` and the shortest edge resized to preserve the aspect ratio. 

The calculation of the other dimension to preserve the aspect ratio is slightly different between the libraries. In pytorch the length of the edge is found [using `int` to round](https://github.com/pytorch/vision/blob/511924c1ced4ce0461197e5caa64ce5b9e558aab/torchvision/transforms/functional.py#L383), whereas Pillow [rounds to the value which produces an aspect ratio closest to the original image](https://github.com/python-pillow/Pillow/blob/1e28c8cffd8492af6bf5df2045e7ffe08b124033/src/PIL/Image.py#L2505). The torchvision resizing logic is replicated in our image transforms library [here](https://github.com/huggingface/transformers/blob/ae1cffaf3cd42d0ab1d7529e3b3118725bca0bcf/src/transformers/image_transforms.py#L155). 

In the test [`tests/models/vision_encoder_decoder/test_modeling_vision_encoder_decoder.py::DonutModelIntegrationTest::test_inference_docvqa`](https://github.com/huggingface/transformers/blob/6cc06d17394f5715cdf2d13a1ef7680bedaee9e2/tests/models/vision_encoder_decoder/test_modeling_vision_encoder_decoder.py#L816), the input image to the `thumbnail` method has dimension `(3713, 1920)`. The requested size is `(2560, 1920)`. `image.thumbnail` will resize to `(2560, 1373)` and our resizing logic (matching torchvision) will resize to `(2560, 1374)`.

As using torchvision resizing logic is more consistent with the rest of the library; Donut is the only model in the library that used the Pillow thumbnail functionality, and is more experimental than other models; I considered this to be an acceptable change. 

## 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?
- [ ] 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.
- [ ] 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).
- [ ] Did you write any new necessary tests?
_The documentation is not available anymore as the PR was closed or merged._<|||||>> Thanks @amyeroberts . LGTM, but I don't see any change related to
> 
> ```
> Resolve bug where size wasn't passed to do_align_axis
> ```
> 
> Do I miss anything?

Nope - I've pushed it now :) <|||||>@sgugger @ydshieh This also uncovered another sneaky bug when resizing: 

* When resizing, the image is coverted to `PIL.Image.Image` from numpy. The channel dimension format of the input image, before resizing inferred is also inferred. 
* When the image is converted back to numpy the image is always in `"ChannelDimension.LAST"` format
* A final `to_channel_dimension_format` call is made to make sure the output resized image is in the same channel dimension format as the input.
* In `to_channel_dimension_format` the input image (resized in this case) channel dimension format is inferred and compared to the requested format. 
* If the `height` dimensions is of size 3 or 1, then format is incorrectly inferred as `ChannelDimension.FIRST`
* This resulted in images in the incorrect format being returned after resizing

For practical purposes, this doesn't cause an issue as it's very unlikely an image has a height dimension of 3. However, it results in flaky tests and is a bug. 

I've added an optional `input_channel_dimension` argument to `to_channel_dimension_format` which resolves this and additional tests for our `resize` functionality which previously failed and now pass with this update. 