[DOCS] Remove some api 1.0 names and mentions from dev docs (openvinotoolkit#22873)

### Details:
 - Remove some api 1.0 names and mentions from dev docs
 
### Tickets:
 - CVS-132237

Author: olpipi

src/bindings/c/docs/api_overview.md

@@ -1,4 +1,4 @@
-# Overview of OpenVINO C* API 2.0
+# Overview of OpenVINO C* API
 
 This API provides a simplified interface for OpenVINO functionality that allows to:
 

src/core/README.md

@@ -15,7 +15,6 @@ People from the [openvino-ngraph-maintainers](https://github.com/orgs/openvinoto
 ## Components
 
 OpenVINO Core has the next structure:
- * [builders](./builder) is obsolete component which provides helper methods for operation creations. Please don't use this API, and use public OpenVINO API instead.
  * [dev_api](./dev_api) contains developer API. In order to use this API, you need to link your component against `openvino::runtime::dev`.
  * [docs](./docs) contains developer documentation pages for the component.
  * [include](./include) contains public API. Detailed information about provided API can be found [here](./docs/api_details.md).

src/core/docs/api_details.md

@@ -6,12 +6,12 @@ OpenVINO Core API contains two folders:
 ## Structure of Core API
 <pre>
  <code>
- <a href="../include/openvino">openvino/</a>                  // Common folder with OpenVINO 2.0 API
-    <a href="../include/openvino/core/">core/</a>                   // Contains common classes which are responsible for model representation
-    <a href="../include/openvino/op/">op/</a>                     // Contains all supported OpenVINO operations
-    <a href="../include/openvino/opsets/">opsets/</a>                 // Contains definitions of each official OpenVINO opset
-    <a href="../include/openvino/pass/">pass/</a>                   // Defines classes for developing transformation and several common transformations
-    <a href="../include/openvino/runtime/">runtime/</a>                // Contains OpenVINO tensor definition
+ <a href="../include/openvino">openvino/</a>                  // Common folder with OpenVINO API
+    <a href="../include/openvino/core/">core/</a>             // Contains common classes which are responsible for model representation
+    <a href="../include/openvino/op/">op/</a>                 // Contains all supported OpenVINO operations
+    <a href="../include/openvino/opsets/">opsets/</a>         // Contains definitions of each official OpenVINO opset
+    <a href="../include/openvino/pass/">pass/</a>             // Defines classes for developing transformation and several common transformations
+    <a href="../include/openvino/runtime/">runtime/</a>       // Contains OpenVINO tensor definition
  </code>
 </pre>
 

src/core/docs/operation_enabling_flow.md

@@ -17,7 +17,7 @@
 
 2. Add operation to the dedicated opset file `src/core/include/openvino/opsets/opsetX_tbl.hpp`
 
-3. Implement `evaluate` method for the operation (reference implementation) in the `openvino/core/reference/[src|include]/ngraph/runtime/reference/`. Reference implementation can be called from Template plugin or from OpenVINO (`src/core/src/op/your_operation_name.cpp/hpp`). 
+3. Implement `evaluate` method for the operation (reference implementation) in the `openvino/core/[src|include/openvino]/op/`. Reference implementation can be called from Template plugin or from OpenVINO.
 To not increase the binary size of openvino lib it should be placed in Template plugin unless you are directly asked to put it in the OpenVINO core. While adding reference implementation the following points should be considered:
    * The method should avoid using the template parameters if possible. However, for the small operations like activation functions it is acceptable.
    * The method should be instantiated for practical data types only.

src/core/docs/tests.md

@@ -2,11 +2,10 @@
 
 OpenVINO Core is covered by tests from the binary `ov_core_unit_tests`. This binary can be built by the target with the same name.
 
-OpenVINO Core [tests](../tests/) have next structure:
+OpenVINO Core [tests](../tests/) consists of common and op evaluation tests. Folder have next structure:
  * `conditional_compilation` - tests cover conditional compilation feature
- * `frontend` - PaddlePaddle frontend tests (should be removed in the nearest future)
+ * `frontend` - common frontend tests
  * `models` - test models
- * `op_eval` - tests cover evaluate methods
  * `pass` - tests covers common transformations
  * `type_prop` - type and shape propagation tests
  * `visitors` - tests covers visitor API for all supported operations

src/frontends/onnx/docs/tests.md

@@ -115,7 +115,7 @@ git clone --branch rel-1.8.1 --single-branch --recursive https://github.com/micr
 ```
 - (Optional) To build ONNX Runtime with a non-release OpenVINO version, an additional step is required for the `rel-1.8.1` version:
 ```
-cd <OV_INSTALL_DIR>/deployment_tools/inference_engine && touch version.txt && echo "2021.4" > version.txt
+cd <OV_INSTALL_DIR>/deployment_tools/openvino && touch version.txt && echo "2021.4" > version.txt
 ```
 2. Set up the OpenVINO environment:
 ```

src/inference/README.md

@@ -16,7 +16,7 @@ OpenVINO Inference has the following structure:
  * [include](./include) contains public API. Find more information in the [OpenVINO Inference API](./docs/api_details.md) document.
  * [src](./src) contains sources of the component.
 
-OpenVINO Inference has unit and functional tests. Unit tests are located in [src/tests/unit/inference_engine](../tests/unit/inference_engine/), functional tests are located in [src/tests/functional/inference_engine](../tests/functional/inference_engine/).
+OpenVINO Inference has unit and functional tests. Unit tests are located in [src/inference/tests/unit](tests/unit/), functional tests are located in [src/inference/tests/functional](tests/unit/).
 
 ## See also
 

src/tests/README.md

@@ -9,42 +9,42 @@ This is OpenVINO testing framework. OpenVINO test system contains:
   * Unit test folder for a particular module should replicate `SRC` folder layout of the corresponding tested module to
     allow further developers get better understanding which part of software is already covered by unit tests and where
     to add new tests if needed.
-    > **Example**: There are `network_serializer.h` and `network_serializer.cpp` files within the `src` folder of the
-    tested OpenVINO module. Then, a new `network_serializer_test.cpp` file should be created within the root of
+    > **Example**: There are `compiled_model.hpp` and `compiled_model.cpp` files within the `src` folder of the
+    tested OpenVINO module. Then, a new `compiled_model_test.cpp` file should be created within the root of
     the Unit Test folder for this module. This test file should cover all the classes and methods from the original
     files.
 
-    > **Example**: There is the `ie_reshaper.cpp` file within the `src/shape_infer` subfolder of the tested module. In this case,
+    > **Example**: There is the `reshape.cpp` file within the `src/shape_infer` subfolder of the tested module. In this case,
     a new `shape_infer` subfolder should be created within the root of the Unit Test folder for this module. And a new
-    `ie_reshaper_test.cpp` file should be created within this newly created subfolder. This test file should cover all
+    `reshape_test.cpp` file should be created within this newly created subfolder. This test file should cover all
     the classes and methods from the original file.
 
   * Each Unit Test should cover only the target classes and methods. If needed, all external interface components should
     be mocked. There are common mock objects provided within the common Unit Test Utilities to stub the general
     OpenVINO API classes.
-    > **Example**: There are `cnn_network_impl.hpp` and `cnn_network_impl.cpp` files within the `src` folder of the tested
-    module. In this case, a new `cnn_network_impl_test.cpp` file should be created and it should contain tests on
-    `CNNNetworkImpl` class only.
+    > **Example**: There are `iplugin.hpp` and `iplugin.cpp` files within the `src` folder of the tested
+    module. In this case, a new `iplugin_test.cpp` file should be created and it should contain tests on
+    `IPlugin` class only.
 
   * It is not prohibited to have several test files for the same file from the tested module.
   * It is not prohibited to create a separate test file for specific classes or functions (not for the whole file).
 
 * **Functional tests**
   This test type is used to verify public OpenVINO API. There are following types of functional tests:
-  * `inference_engine_tests` are plugin-independent tests. They are used to verify OpenVINO API methods that do not
-    involve any plugin runtime. The examples are: `network_reader`, `network_serializer`, and `precision` tests.
+  * `openvino_tests` are plugin-independent tests. They are used to verify OpenVINO API methods that do not
+    involve any plugin runtime. The examples are: `model_reader`, `model_serializer`, and `type` tests.
   * `plugin_tests` are plugin-dependent tests. These tests require plugin runtime to be executed during testing. For example,
-    any tests using `ExecutableNetwork`, `InferRequest` API can only be implemented within this test group.
+    any tests using `CompiledModel`, `InferRequest` API can only be implemented within this test group.
 
-  > **Example**: Any new test on creating a CNNNetwork object and checking its output info should be included to
-  the OpenVINO Functional tests suite. However, any new test containing reading of a network and loading it to a
+  > **Example**: Any new test on creating a ov::Model object and checking its output info should be included to
+  the OpenVINO Functional tests suite. However, any new test containing reading of a model and loading it to a
   specified plugin is always the plugin test.
 
   There are following rules which are **required** for Functional Tests development:
   * All Functional tests are separated into different executables for the OpenVINO and each plugin.
   * Pre-converted IR files must not be used within the new Functional Tests. Tested models should be generated during
-    the tests execution. The main method to generate a required model is building of the required NGraph function and
-    creating a CNNNetwork using it. If a required layer is not covered by Ngraph, it is allowed to build IR file using
+    the tests execution. The main method to generate a required model is building of the required OpenVINO model.
+    If a required layer is not covered by OpenVINO, it is allowed to build IR file using
     `xml_net_builder` utility (refer to the `ir_net.hpp` file). IR XML files hardcoded as strings within the test
     code should not be used.
   * All the plugin test cases are parameterized with (at least) the device name and included to the common
@@ -63,7 +63,7 @@ This is OpenVINO testing framework. OpenVINO test system contains:
 
 * **OpenVINO tests utilities**
   The set of utilities which are used by the OpenVINO Functional and Unit tests. Different helper functions,
-  blob comparators, OS-specific constants, etc. are implemented within the utilities.
+  tensor comparators, OS-specific constants, etc. are implemented within the utilities.
   Internal namespaces (for example, `ov::test::utils::`) must be used to
   separate utilities by domains.