Add building wheel packages

[antonwolfy]

This PR extends build scripts to enable building of wheel packages.

The changes are based on the internal scripts used by the Infrastructure team to build mkl-service wheel packages.

The main difference is to use wheel tags command instead of auditwheel repair one which might broke loading of MKL libs.
That may happen because auditwheel repair creates isolated lib/python3.x/site-packages/mkl_service.libs folder with only libmkl_rt-*.so.2 lib included and there is no rpath set to a folder with all other MKL libs require for proper loading.

Additionally, the PR adds explicit specifies runtime library directories towards expecting MKL libs folder in the virtual env to have this working out of the box there.

Also, the GitHub workflow Conda package is proposing to be extended to upload the wheel packages.

[ekomarova]

Should we do something like this https://github.com/IntelPython/dpnp/blob/master/conda-recipe/meta.yaml#L10 here https://github.com/IntelPython/mkl-service/pull/85/files#diff-330610924437ff65867549da646165faa154ae5201567339b33169f521c084b2R6?

[antonwolfy]

Should we do something like this https://github.com/IntelPython/dpnp/blob/master/conda-recipe/meta.yaml#L10 here https://github.com/IntelPython/mkl-service/pull/85/files#diff-330610924437ff65867549da646165faa154ae5201567339b33169f521c084b2R6?

Yep, it was my initial intention also, but I rolled back these changes. And I would prefer to keep that to follow-up PRs, it hasn't block the releasing of the fix.

The real issue here is the tag format. Current approach assume something like v2.5.0 and it that case we can't use GIT_DESCRIBE_TAG I believe. If it is fine to switch to the format like 2.5.0 (without v as a prefix), then we can proceed with reusing GIT_DESCRIBE_TAG.
Btw, I think even it is OK to switch to new tag format without the prefix, I assume it is not a good way to start from the minor release.. But all of this, of course, can be debated.

[antonwolfy]

@ndgrigorian, @vtavana please review

[vtavana]

Thank you, @antonwolfy!

The issue IntelPython/dpnp#2505 is resolved when using the wheel artifact created in the CI of this PR.
After downloading the artifact mkl_service-2.5.1-cp310-cp310-manylinux_2_28_x86_64.whl and moving it to a directory named whl.

python3 -m venv test
source test/bin/activate
pip install --no-cache-dir -i https://software.repos.intel.com/python/pypi numpy --find-links ./whl/

one can import numpy without any issues.