Use oneMKL LAPACK gesv for dpnp.linalg.solve()

[vlad-perevezentsev]

This PR suggests using oneMKL LAPACK gesv instead of getrf and getrs in dpnp.linalg.solve() since the issues in oneMKL have been resolved. This removes the workaround implemented in #1763

• 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/index.html

[github-actions]

Array API standard conformance tests for dpnp=0.19.0dev3=py313h509198e_26 ran successfully.
Passed: 1227
Failed: 0
Skipped: 9

[coveralls]

coverage: 71.848% (-0.3%) from 72.19%
when pulling 9a0daa0 on use_gesv_solve
into 8133c3c on master.

[vlad-perevezentsev]

Coverage decrease is expected.
getrs function will be used in the future implementation of dpnp.linalg.lu_solve

[ndgrigorian]

Seems to be having stability issues on Level Zero, internal CI shows it in TestSolve

@vlad-perevezentsev can you investigate if this is acceptable level of error and loosen the test if it is, and otherwise, look at it?

[vlad-perevezentsev]

@ndgrigorian Thank you for noticing this!
This is a typical mistake in tests on machines that do not support 64-bit floating point operations.
It is more correct to use assert_dtype_allclose there.
I have fixed that.

[antonwolfy]

LGTM! Few minor nits below.