Test oneDPL installation through cmake

[dmitriy-sobolev]

Summary:
oneDPL installation through cmake is not automatically and regularly tested. However, it should be.

Problem Statement:
The lack of testing may lead to issues or oversights like the one detected in #1964.

Preferred Solution:
It would be convenient to have a micro cmake project using find_package(oneDPL REQUIRED) and calling some oneDPL APIs, which is a part of the main cmake test suite.

To be more precise, the solution can be:

1. A micro project relying on find_package(oneDPL): e.g. one *.cpp file and CMakeLists.txt.
2. Installing oneDPL.
3. A part of the testing suite. Hence:
   • The folder with the test should reside in https://github.com/oneapi-src/oneDPL/tree/main/test.
   • The test is triggered through a typical cmake command for testing (see the CI as an example).
   • It is Included into build-onedpl-test and run-onedpl-test umbrella targets.
   • It respects the passed ONEDPL_BACKEND as a custom option and built-in options like CMAKE_BUILD_TYPE, CMAKE_CXX_FLAGS and so on.
4. The test itself should test a device policy when available, and a host policy depending on ONEDPL_PAR_BACKEND configuration from oneDPLConfig.cmake.

The pipeline can look as (the approach may be different if there are better ideas, though):

1. CMake is configured, e.g.:
   cmake -DCMAKE_CXX_COMPILER=icpx -DCMAKE_BUILD_TYPE=release -DONEDPL_BACKEND=tbb /path/to/oneDPL. See the full examples in the CI.
2. All targets are build together with this one, e.g.: make build-onedpl-tests. While the new target may do that:
   1. Set up CMAKE_INSTALL_PREFIX=/path/to/install
   2. Install oneDPL: cmake --build . --target install
   3. Configure the micro project: cmake -B /path/to/test_folder/build -DCMAKE_PREFIX_PATH=/path/to/install <other flags> /path/to/test_folder. Other flags should include ONEDPL_PAR_BACKEND (selected according to ONEDPL_BACKEND passed at stage the 1. and other standard cmake flags such as CMAKE_BUILD_TYPE.
   4. Create a target for ctest.
3. All tests are run, e.g.: ctest --output-on-failure.

Additional Notes

The test itself should include the test config for TestUtils::done() needed for ctest to report the status. Other features from the framework may also be needed, such as TestUtils::default_dpcpp_policy.