Add Python scalar support to dpt.where

[ndgrigorian]

This PR proposes a change to dpt.where to add support for Python scalars, aligning it with clip and elementwise functions.

As has been pointed out by the array API community, an common use-case for dpt.where is supporting Python scalars. If the decision to permit them in other elementwise functions is made, where will likely follow suit.

Regardless of the outcome of this decision, it's sensible to support them here.

As the first argument (condition) does not participate in the type promotion in where, if both arguments are scalars, the scalars are treated as the default types for the respective kind.

• 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?
• If this PR is a work in progress, are you opening the PR as a draft?

[github-actions]

Deleted rendered PR docs from intelpython.github.com/dpctl, latest should be updated shortly. 🤞

[github-actions]

Array API standard conformance tests for dpctl=0.18.0dev0=py310h15de555_80 ran successfully.
Passed: 894
Failed: 15
Skipped: 105

[coveralls]

coverage: 87.965% (-0.09%) from 88.057%
when pulling 20929be on support-scalars-in-where
into 26d34f5 on master.

[github-actions]

Array API standard conformance tests for dpctl=0.18.0dev0=py310h15de555_81 ran successfully.
Passed: 894
Failed: 15
Skipped: 105

[coveralls]

coverage: 87.965% (-0.09%) from 88.057%
when pulling 9f449d1 on support-scalars-in-where
into 26d34f5 on master.

[antonwolfy]

I checked the PR in dpnp tests and all tests are passed on GPU and CPU devices.

[ndgrigorian]

CI failure is unrelated to this PR, I will go ahead and merge it