Revert recent fused l2 nn instantiations

[cjnolet]

These instantiations have caused some issues because they expose the cub::KeyValuePair symbol compiled into libraft-distances downstream. Unfortunately, since rapids-cmake transforms the name of the cub symbols to include the list of cuda architectures upon which they are built, any users who link against libraft-distance and don't build their code downstream with that exact list of architectures will get an undefined symbol error.

I had initially removed the symbol from the instantiation by copying the cub::KeyValuePair into RAFT and renaming it to raft::KeyValuePair but it seems this is causing problems for HDBSCAN in the centos7 builds within cuml. cc @Nyrio. I'm reverting these changes for 22.10 to give us an opportunity to fix them in 22.12. While this will have a negative impact on compile times, it will at least allow our tests to pass in cuml.

[Nyrio]

I'm curious what was causing the said problems with HDBSCAN in cuML? Using a custom pair type instead of cub::KeyValuePair seems to be the best solution here.

[cjnolet]

@Nyrio I agree completely, but suddenly an hdbscan test started failing in the centos build after this change (seeming intermittently but still happening 3/4 if the time) and we are in a crunch for code freeze, which technically started already. I hope backing this out is enough to fix the failing test and then we can investigate further in 22.12.

[cjnolet]

@gpucibot merge