Streaming in G-API

This PR introduces basic streaming support in G-API. Now G-API can
handle video streams and pipeline the execution (especially
heterogeneous & inference) efficiently, thus maximizing the overall
throughput.

API Overview

Now in addition to a regular GComputation::compile() a user can
compile the same (exactly the same!) graph for streaming -- via
GComputation::compileStreaming(). The returned object is
GStreamingCompiled -- a stream-oriented version of a compiled graph.
Use setSource(), start(), and stop() methods to specify the
input data (stream or constant), start the processing, and stop it,
respectively. Use methods pull() or try_pull() to obtain a /next
processed frame/ data from the pipeline in synchronous/asynchronous
mode, respectively.

Creating and running a pipeline is now as easy as:

cv::GMat in;
auto roi = cv::gapi::crop(in, crop_rc);
auto res = cv::gapi::resize(roi, resample_sz);
auto out = cv::gapi::Canny(res, thr_lo, thr_hi);
auto ccomp = cv::GComputation(cv::GIn(in), cv::GOut(out))
    .compileStreaming(cv::GMatDesc{CV_8U,3,cv::Size{768,576}});
ccomp.setSource(cv::gin(gapi::wip::make_src<cv::gapi::wip::GCaptureSource>
    (findDataFile("cv/video/768x576.avi"))));
ccomp.start();
cv::Mat out_mat_gapi;
while (ccomp.pull(cv::gout(in_mat_gapi))) {
    // Handle your pipeline-processed data here.
}
// Reaching this point means that stream is over (or pipeline was stopped)

Note that a generic version of setSource() takes a vector of input
data sources via cv::gin(), and the output data vector is written by
pull()/try_pull() into objects passed via cv::gout(); it is very
similar how regular GComputation::apply() or GCompiled::operator()
work.

compileStreaming also takes G-API compilation arguments similar to a
regular compile() -- so custom kernels, backend selection, and
debugging options are welcome!

Implementation overview

The streaming implementation relies heavily on the existing G-API's
heterogeneous infrastructure. If G-API runs a mixture of kernels from
different backends (e.g., OpenCV, Fluid, Inference), the appropriate
graph nodes for these backends are organized into clusters called
"Islands". Kernels in every "Island" belong to the same
device/backend. Islands are regions in the Directed Acyclic Graph (the
G-API's underlying representation model).

Current streaming implementation makes these Islands run in parallel.
Currently it is done naively by assigning every Island to its own
dedicated thread. Since Islands are connected earch other at the graph
level, the execution threads are connected appropriately too (there is a
direct 1:1 mapping).

Island graph model is a bipartite graph with Islands ("super-nodes" or
"super-operations") connected each other via Data objects.

A Data object can be written by only one Island (exclusively) and can
be read from multiple other Islands.

In Streaming mode, every READ edge for Data node is associated with
its own queue (tbb::concurrent_bounded_queue or our own equivalent
if TBB is not available). Reader Islands poll their input queues and
fetch elements to a vector to form a call frame.

Writer Islands produce data and write it to ALL queues associated with
every output Data object at the graph level.

When a graph is compiled for Streaming, the Island Graph model is
extended with some extra nodes to maintain the above invariant &
reduce complexity: Emitters and Sinks.

Emitters push the input data (whether it is a video stream's next
frame or a constant ("frozen" in GStreamer terms) Mat or scalar) its
queues, which are then consumed by first Islands in the graph.

Sinks collect data from the last (output) Islands in the graph and
synchronize the data (if a pipeline has multiple outputs) to one
single vector to make the implementation of try_pull()/pull()
easier.

When there's no data anymore or stop() was called explicitly, a
special STOP sign is pushed by emitters/to internal queues and then
broadcasted to the rest of the pipeline. Some complex logic is
involved to avoid deadlocks in this situation.

Current limitations

• A couple of bugs has been found on GArray<> and util::variant --
  all were reported internally, workarounded gracefully, and to be
  addressed within a release or two.
• Design on input video source is not yet closed so the appropriate
  objects are declared under cv::gapi::wip namespace.

force_builders=Custom,Custom Win,Custom Mac
build_image:Custom=ubuntu-openvino-2019r2.0:16.04
build_image:Custom Win=openvino-2019r2.0
build_image:Custom Mac=openvino-2019r2.0
test_modules:Custom=gapi
test_modules:Custom Win=gapi
test_modules:Custom Mac=gapi
buildworker:Custom=linux-1
test_opencl:Custom=ON
test_bigdata:Custom=1
test_filter:Custom=*
build_gapi_standalone:Linux x64=ade-0.1.1f
build_gapi_standalone:Win64=ade-0.1.1f
build_gapi_standalone:Mac=ade-0.1.1f
build_gapi_standalone:Linux x64 Debug=ade-0.1.1f
build_gapi_standalone:Custom Win=ade-0.1.1f