feat: add reduction ops conversion for MPI + cleanup impl

[dssgabriel]

• Make reduction operator conversion CommSpace-generic
  • Perform necessary changes for NCCL
• Added conversion logic between KokkosComm's reduction operators and MPI_Op
  • Added missing LXor and BXor operators
• Cleaned up primary impl header
  • updated (missed) copyright header
  • fix includes (IWYU)
  • removed unnecessary namespace prefixing

[cedricchevalier19]

LGTM

[cedricchevalier19]

I am not sure how to test the dispatch logic, perhaps adding a unit test that almost looks like your implementation but that can save us later when changing the reduction op dispatch.

Can you use these reduction op in MPI, in this PR?

Can we make something to be able to know if a reduction operator is implemented for a given CommunicationSpace?

[dssgabriel]

perhaps adding a unit test that almost looks like your implementation, but that can save us later when changing the reduction op dispatch

Yes, definitely. I will add conversion tests in this PR.

---

Can you use these reduction op in MPI, in this PR?

Do you mean for the existing low-level MPI reduction interfaces we have? I could, but this would mean that these no longer take an MPI_Op parameter, which would not be consistent with what I did for the low-level NCCL bindings (which take an ncclRedOp_t parameter instead). As I understand our design logic, low-level bindings (the ones in the mpi:: or nccl:: sub-namespaces) use the backend's own data types (e.g. MPI_Comm/ncclComm_t, etc.).
PRs #197 and #199 are the ones that introduce the use of the generic KokkosComm::ReductionOperator concepts for their reduction op parameter, since they are part of the core API (consistent with the NCCL specialization).

---

Can we make something to be able to know if a reduction operator is implemented for a given CommunicationSpace?

I could write a helper function like:

template <CommunicationSpace CS, ReductionOperator RO>
auto is_reduction_op_convertible() -> bool;

Is this what you meant?

Additionally, this could become part of the constraints on the ReductionOperator concept, which may allow us to produce better diagnostics if a reduction operator isn't available for a given backend.