Misleading output names; must be changed

While conda-forge has its fair share of naming quirks whether something is a python library, a C/C++ library (and whether that uses the `libfoo` pattern), or whatever, one pattern is clear: If there's both `foo` and `foo-static`, then `foo` is the shared library and `foo-static` is the static library _on top_ of the shared one.

Here in contrast, there's _only_ a static library for the C part ([`ittapi-static`](https://conda-metadata-app.streamlit.app/?q=conda-forge%2Flinux-64%2Fittapi-static-3.26.4-hecca717_0.conda)), and what _sounds_ like the shared library are actually the python bindings ([`ittapi`](https://conda-metadata-app.streamlit.app/?q=conda-forge%2Flinux-64%2Fittapi-3.26.4-py313h7033f15_0.conda)). Given that the python bindings are also called `ittapi` on [PyPI](https://pypi.org/project/ittapi/), I suggest the following rename (but other options exist):

| Before | After | Comment |
|--------|--------|--------|
| - | `libittapi` or
`libitt` or
`libittnotify` | Unless there are strong technical reasons that render this
impossible, there should be a shared library following
[CFEP-18](https://github.com/conda-forge/cfep/blob/main/cfep-18.md); various name choices |
| `ittapi-static` | `libitt[...]-static` | Needs to match shared library output name|
| `ittapi` | `ittapi` | Python bindings |

Start with the ittapi-feedstock configuration and inspect the package metadata linked in the issue, then read CFEP-18. Determine whether a shared C library can be produced and choose consistent names for the shared, static, and Python-binding outputs. Done means the output names no longer imply that the Python package is the shared library and the static package matches the shared-library name.

Written by the indexing model from the issue text.