Raise not-implemented exception on numpy fallback

[antonwolfy]

Previously DPNP fell back on NumPy implementation when a requested functionality isn't available and can't be provided by DPNP.
The PR is indented to raise Non-implemented exception in that scenario by default, rather than falling back.

It will be possible to keep old behavior with falling back on NumPy calls by setting a new environment variable DPNP_RAISE_EXCEPION_ON_NUMPY_FALLBACK = 0.
In all other cases, the fallback is prohibited and lead to the exception.

• Have you provided a meaningful PR description?
• Have you added a test, reproducer or referred to 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?
• If this PR is a work in progress, are you filing the PR as a draft?

[oleksandr-pavlyk]

Implementation in this PR falls back by default, allows opting out. I should clarify, but I thought we agreed to raises by default, permits opt-in.

[oleksandr-pavlyk]

Implementation in this PR falls back by default, allows opting out. I should clarify, but I thought we agreed to raises by default, permits opt-in.

Never mind I misread the code, it works as expected

[oleksandr-pavlyk]

Perhaps factor out uses of numpy.isfinite into your own routine which can be modified as needed.

If scale always remains a Python or NumPy scalar, than not compute-follows-data violation occurs, but if scale can be an array, then your modular routine can be modified to apply appropriate validation function.

[antonwolfy]

Added internal functions _is_finite_scalar() and _is_finite_scalar() to dpnp_random_state.py with TODO comment inside to replace with dpnp functionality once availbale.