Merge pull request #16050 from dmatveev:dm/ocv42_gapi_doc_fixup

* G-API: Addressed various documentation issues

- Fixed various typos and missing references;
- Added brief documentaion on G_TYPED_KERNEL and G_COMPOUND_KERNEL macros;
- Briefly described GComputationT<>;
- Briefly described G-API data objects (in a group section).

* G-API: Some clean-ups in doxygen, also a chapter on Render API

* G-API: Expose more graph compilation arguments in the documentation

* G-API: Address documentation review comments

modules/gapi/doc/00-root.markdown

@@ -64,7 +64,7 @@ included explicitly. The first four lines of `main()` create and
 initialize OpenCV's standard video capture object, which fetches
 video frames from either an attached camera or a specified file.
 
-G-API pipelie is constructed next. In fact, it is a series of G-API
+G-API pipeline is constructed next. In fact, it is a series of G-API
 operation calls on cv::GMat data. The important aspect of G-API is
 that this code block is just a declaration of actions, but not the
 actions themselves. No processing happens at this point, G-API only

modules/gapi/doc/10-hld-overview.md

@@ -1,11 +1,12 @@
 # High-level design overview {#gapi_hld}
 
-# G-API High-level design overview
-
 [TOC]
 
-G-API is a heterogeneous framework and provides single API to program
-image processing pipelines with a number of supported backends.
+# G-API High-level design overview
+
+G-API is a heterogeneous framework and provides an unified API to
+program image processing pipelines with a number of supported
+backends.
 
 The key design idea is to keep pipeline code itself platform-neutral
 while specifying which kernels to use and which devices to utilize
@@ -54,7 +55,7 @@ their own kernels easily using a special macro G_TYPED_KERNEL().
 API layer is also responsible for marshalling and storing operation
 parameters on pipeline creation. In addition to the aforementioned
 G-API dynamic objects, operations may also accept arbitrary
-parameters (more on this [below](@ref gapi_detail_params)), so API
+parameters (more on this [here](@ref gapi_detail_params)), so API
 layer captures its values and stores internally upon the moment of
 execution.
 
@@ -143,7 +144,7 @@ Both methods are polimorphic and take a variadic number of arguments,
 with validity checks performed in runtime. If a number, shapes, and
 formats of passed data objects differ from expected, a run-time
 exception is thrown. G-API also provides _typed_ wrappers to move
-these checks to the compile time -- see cv::GComputationT<>.
+these checks to the compile time -- see `cv::GComputationT<>`.
 
 G-API graph execution is declared stateless -- it means that a
 compiled functor (cv::GCompiled) acts like a pure C++ function and
@@ -154,6 +155,6 @@ number of inputs, and \f$M\f$ is a number of outputs on which a
 cv::GComputation is defined. Note that while G-API types (cv::GMat,
 etc) are used in definition, the execution methods accept OpenCV's
 traditional data types (like cv::Mat) which hold actual data -- see
-table in [parameter marshalling](@#gapi_detail_params).
+table in [parameter marshalling](@ref gapi_detail_params).
 
 @sa @ref gapi_impl, @ref gapi_kernel_api

modules/gapi/doc/20-kernel-api.markdown

@@ -54,10 +54,10 @@ handled in a special way. All other types are opaque to G-API and
 passed to kernel in `outMeta()` or in execution callbacks as-is.
 
 Kernel's return value can _only_ be of G-API dynamic type -- cv::GMat,
-cv::GScalar, or cv::GArray<T>. If an operation has more than one output,
-it should be wrapped into an `std::tuple<>` (which can contain only
-mentioned G-API types). Arbitrary-output-number operations are not
-supported.
+cv::GScalar, or `cv::GArray<T>`. If an operation has more than one
+output, it should be wrapped into an `std::tuple<>` (which can contain
+only mentioned G-API types). Arbitrary-output-number operations are
+not supported.
 
 Once a kernel is defined, it can be used in pipelines with special,
 G-API-supplied method "::on()". This method has the same signature as
@@ -141,7 +141,7 @@ just follow the signature conventions defined by the plugin. G-API
 will call this method during execution and supply all the necessary
 information (and forward the original opaque data as-is).
 
-# Compound kernels
+# Compound kernels {#gapi_kernel_compound}
 
 Sometimes kernel is a single thing only on API level. It is convenient
 for users, but on a particular  implementation side it would be better to

modules/gapi/doc/30-implementation.markdown

@@ -2,26 +2,28 @@
 
 [TOC]
 
-# G-API Implementation details {#gapi_impl_header}
+# G-API Implementation details
 
-## Api layer details {#gapi_detail_api}
+Note -- this section is still in progress.
 
-### Expression unrolling {#gapi_detail_expr}
+# API layer {#gapi_detail_api}
 
-### Parameter marshalling {#gapi_detail_params}
+## Expression unrolling {#gapi_detail_expr}
 
-### Operations representation {#gapi_detail_operations}
+## Parameter marshalling {#gapi_detail_params}
 
-## Graph compiler details {#gapi_detail_compiler}
+## Operations representation {#gapi_detail_operations}
 
-### ADE basics {#gapi_detail_ade}
+# Graph compiler {#gapi_detail_compiler}
 
-### Graph model representation {#gapi_detail_gmodel}
+## ADE basics {#gapi_detail_ade}
 
-### G-API metadata and passes {#gapi_detail_meta}
+## Graph model representation {#gapi_detail_gmodel}
 
-## Backends details {#gapi_detail_backends}
+## G-API metadata and passes {#gapi_detail_meta}
 
-### Backend scope of work {#gapi_backend_scope}
+# Backends {#gapi_detail_backends}
 
-### Graph transformation {#gapi_backend_pass}
+## Backend scope of work {#gapi_backend_scope}
+
+## Graph transformation {#gapi_backend_pass}