Describe the feature and motivation

G-API is quite interesting technology following a long tradition of graph engines. It's targeted for efficient streaming video/image processing on a variety of devices.

On the other hand, during all this time while G-API is included into OpenCV, it does not look connected or integrated with other parts. It uses different API for video capturing beyond VideoCapture/VideoWriter, it uses different API for inferencing, not OpenCV DNN, it reoptimizes some basic image processing operations without contributing it back to imgproc. It uses quite different coding style. It's quite heavy.

Now, in OpenCV 5 we are going to seriously revise DNN module, where there will be convenient API (similar to PyTorch) to construct graph out of operations. And, of course, it will support pre-recorded and pre-tained graphs in ONNX, TF and other formats. It will also, just like G-API, support GPUs and other accelerators. In other words, with sufficent set of operations OpenCV 5 DNN can play the role of G-API and yet be more practical because of deep learning model support w/o 3rd-party dependencies.

So, to make OpenCV 5 cleaner and smaller it's suggested to move G-API to opencv_contrib or maybe to a separate repository to let it develop separately from OpenCV, as it's logically not a part of OpenCV but rather an engine on top of OpenCV since the very beginning.

Additional context

No response