expand has_any and has_all to also accept check callables

[pmeier]

This is useful if the type checking involves more than plain types. A common example is to check for an image in the sample which is done with the types features.Image and PIL.Image.Image as well as the check function is_simple_tensor. With this PR, we can pass all three to has_any and has_all:

import PIL.Image
import torch
from torchvision.prototype import features
from torchvision.prototype.transforms._utils import has_any, is_simple_tensor
from torchvision.prototype.transforms.functional import to_image_pil

image_tensor = torch.rand(3, 16, 16)
image_pil = to_image_pil(image_tensor)
image = features.Image(image_tensor)

for input in [image_tensor, image_pil, image]:
    assert has_any(input, PIL.Image.Image, features.Image, is_simple_tensor)

This PR also uses this new idiom to add support for simple tensors to CutMix and MixUp as well as RandomIoUCrop as discussed in #6401 (comment).

[datumbox]

@pmeier This might be a matter of styles and preferences, but I have hard time reading code that is so densely written as this. I understand that some people like it as it's more pythonic.

@vfdev-5 thoughts?

[datumbox]

LGTM. I've added a few optional comments above, I haven't thoroughly checked it as I am in between meetings. Feel free to ignore.

[pmeier]

They are asymmetric because the behavior we want for has_any is any(any(...)) and for has_all is any(all(...)). If has_all would be all(all(...)) they would be symmetric.