[Pipeline] skip feature extraction test if in `IMAGE_PROCESSOR_MAPPING`
# What does this PR do?

Fixes the [following failing test](https://app.circleci.com/pipelines/github/huggingface/transformers/53884/workflows/8df76bfb-b6d2-493e-afdf-257b59672b02/jobs/648580)

## Context:

Currently `FeatureExtractionPipelineTests` are skipped for multi-modal models by checking if the model config is in `FEATURE_EXTRACTOR_MAPPING`. The check is done [on this line](https://github.com/huggingface/transformers/blob/1543cee7c8c95ef47f832b1f37625ba2923c4994/tests/pipelines/test_pipelines_feature_extraction.py#L181) 
Recent vision and multimodal models will deprecate the usage of `xxxFeatureExtractor` in favor of `xxxImageProcessors`. For [Blip](https://github.com/huggingface/transformers/pull/20716), the test fails because `BlipFeatureExtractor` is not implemented at all in favor of `BlipImageProcessor`.

## Why this fix is relevant?

Blip seems to be the first multimodal model that relies on `xxxImageProcessor` only. 

cc @Narsil @amyeroberts @NielsRogge 
_The documentation is not available anymore as the PR was closed or merged._<|||||>Thanks
I am not sure about how do we want to approach that exactly, but I think that's the plan at some point cc @amyeroberts :D <|||||>> Thanks I am not sure about how do we want to approach that exactly, but I think that's the plan at some point cc @amyeroberts :D

I think it's good to disambiguate Audio from Vision (both are currently named `FeatureExtractor` I think).

In that regard I'd like to stress to include no-code (or almost none) into `Processor` the general class that encapsulates `Tokenizer`, `FeatureExtractor` and `ImageProcessor` . It's great for demos and quick hacks, but it's much more cumbersome to reason about within a lib, as it's impossible to know what it should be able to do since it's by definition not standard. (It doesn't have any invariant).

For instance `Tokenizer.encode(text)` is always going to be a valid call and will return ids (that's an invariant).