Unvendor onednn

We have largely moved away from aggressive unvendoring but it might still be good to unvendor a few packages.

One that was identified is onednn.

Lets discuss here instead of the old https://github.com/conda-forge/pytorch-cpu-feedstock/issues/108 where the aggressive plan was the focus of the discussion.

> I'd still be in favour of building on top of a system onednn. Avoiding recompilation and revendoring of various bits is IMO almost always welcome, and certainly for big pieces like onednn.
>
> The argument to wait for a stable API is fine for me, but OTOH, whether we're using the experimental API implicitly (through the vendored onednn) or explicitly (through a variant packaged by us) doesn't really make a big difference.
>
> In any case, we should do it in principle, at least as soon as the experimental bits aren't necessary anymore (but I'd be open to do it sooner). Also, this issue contains a lot of useful information, and some other pieces might still be worth splitting off. We should open follow-up issues IMO (at least for onednn, but I'd also love to see https://github.com/conda-forge/staged-recipes/pull/19103 progress and get used).

_Originally posted by @h-vetinari in [#108](https://github.com/conda-forge/pytorch-cpu-feedstock/issues/108#issuecomment-2571677930)_