Enable clip test from array-api-tests scope

[antonwolfy]

There were few fixes implemented in array-api-tests around clip tests.
The PR proposes to enable test_clip test from array-api-tests scope.

• Have you provided a meaningful PR description?
• Have you added a test, reproducer or referred to an issue with a reproducer?
• Have you tested your changes locally for CPU and GPU devices?
• Have you made sure that new changes do not introduce compiler warnings?
• Have you checked performance impact of proposed changes?
• Have you added documentation for your changes, if necessary?
• Have you added your changes to the changelog?

[github-actions]

View rendered docs @ https://intelpython.github.io/dpnp/pull/2386/index.html

[github-actions]

Array API standard conformance tests for dpnp=0.18.0dev0=py312he4f9c94_43 ran successfully.
Passed: 1005
Failed: 1
Skipped: 44

[antonwolfy]

The issue is still present and caused by dpctl-1742:

File "/home/runner/miniconda3/envs/array-api-conformity/lib/python3.12/site-packages/dpctl/tensor/_clip.py", line 463, in clip
    raise ValueError(
ValueError: function '<function clip at 0x7f52e1a619e0>' does not support input types (uint8, uint8, uint16), and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''.
Falsifying example: test_clip(
    x=array(0, dtype=uint8),
    data=data(...),
...

[coveralls]

coverage: 72.142%. remained the same
when pulling 0635fcf on enable-clip-tests
into 395c896 on master.

[ndgrigorian]

The issue is still present and caused by dpctl-1742:

File "/home/runner/miniconda3/envs/array-api-conformity/lib/python3.12/site-packages/dpctl/tensor/_clip.py", line 463, in clip
    raise ValueError(
ValueError: function '<function clip at 0x7f52e1a619e0>' does not support input types (uint8, uint8, uint16), and the inputs could not be safely coerced to any supported types according to the casting rule ''safe''.
Falsifying example: test_clip(
    x=array(0, dtype=uint8),
    data=data(...),
...

I still think this may be a mistake in the array API tests

Per spec,
"If either min or max is an array having a different data type than x, behavior is unspecified and thus implementation-dependent."

Also,
"Clarified that behavior is only defined when x, min, and max resolve to arrays having the same data type."

[ndgrigorian]

Regardless of our intended solution, we can file this with the array API tests as an incorrectly designed test.

It may have been more convenient to just enable type promotion in clip after all... perhaps if NumPy makes a stronger decision it can be considered.