Add sklearnex interface for polynomial kernel

[SnigdhaSarkar16]

This PR introduces a new poly_kernel interface in the sklearnex.svm module that wraps the existing oneDAL poly_kernel implementation.

The function supports X, Y, gamma, coef0, degree, and optional SYCL queue.

Includes tests in sklearnex/svm/tests/test_poly_kernel_sklearnex.py to validate correctness.

All code passes pre-commit checks, including black, isort, and numpydoc.

This enhancement allows Scikit-learn users to leverage the oneDAL backend for polynomial kernel computations via sklearnex.

[codecov[bot]]

Codecov Report

:x: Patch coverage is 80.00000% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
sklearnex/svm/poly_kernel.py	80.00%	1 Missing and 1 partial :warning:

Flag	Coverage Δ
azure	80.47% <80.00%> (-0.01%)	:arrow_down:
github	82.07% <ø> (-0.02%)	:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
sklearnex/svm/poly_kernel.py	80.00% <80.00%> (ø)

... and 1 file with indirect coverage changes

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[SnigdhaSarkar16]

Hi @icfaust Thank you for the feedback! I understand that the poly_kernel function should interface with scikit-learn’s polynomial_kernel to handle sparse inputs and replicate its signature. I’ll update the code accordingly and add appropriate tests. Thankyou!!!

[SnigdhaSarkar16]

Hey @icfaust , just checking in , all checks except docs are green. Should I do anything to fix the docs build, or can it be merged as is?

[icfaust]

@SnigdhaSarkar16 sorry this will require more work on this than its current form. I recommend getting acquainted with our checklist

<!--
PR should start as a draft, then move to ready for review state
after CI is passed and all applicable checkboxes are closed.
This approach ensures that reviewers don't spend extra time asking for regular requirements.

You can remove a checkbox as not applicable only if it doesn't relate to this PR in any way.
For example, a PR with docs update doesn't require checkboxes for performance
while a PR with any change in actual code should list checkboxes and
justify how this code change is expected to affect performance (or justification should be self-evident).
-->

<details>
<summary>Checklist:</summary>

**Completeness and readability**

- [ ] I have commented my code, particularly in hard-to-understand areas.
- [ ] I have updated the documentation to reflect the changes or created a separate PR with updates and provided its number in the description, if necessary.
- [ ] Git commit message contains an appropriate signed-off-by string _(see [CONTRIBUTING.md](https://github.com/uxlfoundation/scikit-learn-intelex/blob/main/CONTRIBUTING.md#pull-requests) for details)_.
- [ ] I have resolved any merge conflicts that might occur with the base branch.

**Testing**

- [ ] I have run it locally and tested the changes extensively.
- [ ] All CI jobs are green or I have provided justification why they aren't.
- [ ] I have extended testing suite if new functionality was introduced in this PR.

**Performance**

- [ ] I have measured performance for affected algorithms using [scikit-learn_bench](https://github.com/IntelPython/scikit-learn_bench) and provided at least a summary table with measured data, if performance change is expected.
- [ ] I have provided justification why performance and/or quality metrics have changed or why changes are not expected.
- [ ] I have extended the benchmarking suite and provided a corresponding scikit-learn_bench PR if new measurable functionality was introduced in this PR.

</details>