API: Simplification of `PairwiseDistanceReductions` backend class names.

## Problem

The current backend class names are a bit confusing:

<details>
<summary>Current Names</summary>

```
# High-level diagram
# ------------------
#
#    Legend:
#
#      A ---⊳ B: A inherits from B
#      A ---x B: A dispatches to B
#
#
#                               (base dispatcher)
#                           PairwiseDistancesReduction
#                                       ∆
#                                       |
#                                       |
#                     +-----------------+-----------------+
#                     |                                   |
#               (dispatcher)                        (dispatcher)
#         PairwiseDistancesArgKmin           PairwiseDistancesRadiusNeighbors
#               |                                              |
#               |                                              |
#               |                                              |
#               |                  (64bit implem.)             |
#               |          PairwiseDistancesReduction64        |
#               |                       ∆                      |
#               |                       |                      |
#               |                       |                      |
#               |     +-----------------+-----------------+    |
#               |     |                                   |    |
#               |     |                                   |    |
#               x     |                                   |    x
#        PairwiseDistancesArgKmin64       PairwiseDistancesRadiusNeighbors64
#               |     ∆                                   ∆    |
#               |     |                                   |    |
#               x     |                                   |    |
#     FastEuclideanPairwiseDistancesArgKmin64             |    |
#                                                         |    |
#                                                         |    x
#                                  FastEuclideanPairwiseDistancesRadiusNeighbors64
```
</details>

The length of the names, especially the further down the hierarchy you go, I think impede the readability of the code as well as make it a bit more confusing to determine the specific roles of everything. For example, it is not obvious to me in the code that `PairwiseDistancesReduction64` and `PairwiseDistancesArgKmin` are wildly different, and while the diagram is helpful I don't think it should be as necessary as it is right now.


## Proposed Solution 1
Edit: Changed `Agent` to `Core` per discussion w/ @jjerphan

With the recent refactoring into a proper submodule, I think we can greatly simplify the namespace. See proposed naming scheme:
<details>
<summary>Proposed Names</summary>

```
# High-level diagram
# ------------------
#
#    Legend:
#
#      A ---⊳ B: A inherits from B
#      A ---x B: A dispatches to B
#
#
#                               (base dispatcher)
#                                   Dispatcher
#                                       ∆
#                                       |
#                                       |
#               +-----------------------+----------------------+
#               |                                              | 
#          (dispatcher)                                   (dispatcher)
#       ArgKminDispatcher                          RadiusNeighborsDispatcher
#               |                                              |
#               |                                              |
#               |                                              |
#               |                (64bit implem.)               |
#               |                     Core                     |
#               |                       ∆                      |
#               |                       |                      |
#               |                       |                      |
#               |     +-----------------+-----------------+    |
#               |     |                                   |    |
#               |     |                                   |    |
#               x     |                                   |    x
#            ArgKminCore64                         RadiusNeighborsCore64
#               |     ∆                                   ∆    |
#               |     |                                   |    |
#               x     |                                   |    |
#        EuclideanArgKminCore64                           |    |
#                                                         |    |
#                                                         |    x
#                                               EuclideanRadiusNeighborsCore64
```
</details>

This draws a more literal connection between the different classes and makes it easily inferred from the code itself, making the diagram a helpful resource rather than a necessary guide.

In general, I think if we follow the current implementation plan of only exposing the dispatchers and implementing each dispatch branch in a separate file (e.g. the branch following `ArgKminDispatcher` lives in `_argkmin.pyx`) we could be a bit more aggressive in trimming the names (i.e. no more explicit `Agent` in name, so `RadiusNeighborsAgent64-->RadiusNeighbors64`) but I can see why some people may not enjoy that.

## Proposed Solution 2

Edit: I added a bar for `Specializations` just to make it more obvious that there isn't necessarily semantic changes below that point, just overwriting relevant methods with faster, more specialized implementations. Optional, but I think it's nice. I also removed the `Agent` suffix to demonstrate a more minimal namespace:

<details>
<summary>More Drastic Change</summary>

```
# High-level diagram
# ------------------
#
#    Legend:
#
#      A ---⊳ B: A inherits from B
#      A ---x B: A dispatches to B
#
#
#                               (base dispatcher)
#                                   Dispatcher
#                                       ∆
#                                       |
#                                       |
#               +-----------------------+----------------------+
#               |                                              | 
#          (dispatcher)                                   (dispatcher)
#       ArgKminDispatcher                          RadiusNeighborsDispatcher
#               |                                              |
#               |                                              |
#               |                (64bit implem.)               |
#               |                     Core                     |
#               |                       ∆                      |
#               |                       |                      |
#               |                       |                      |
#               |     +-----------------+-----------------+    |
#               |     |                                   |    |
#               |     |                                   |    |
#               x     |                                   |    x
#              ArgKmin64                            RadiusNeighbors64
#               |     ∆                                   ∆    |
#               |     |                                   |    |
#      ========================= Specializations ==============================
#               |     |                                   |    |
#               |     |                                   |    |
#               x     |                                   |    x
#          EuclideanArgKmin64                    EuclideanRadiusNeighbors64
```
</details>

cc: @jjerphan

COMMENT:
> `Agent`? Do you want to bring a specific semantic?

I wanted to communicate that the main definition for specific computation routines lies within the implementers of `Agent` -- that is to say, classes like `ArgKminAgent64` and `RadiusNeighborsAgent64` define the _agency_ of the algorithm in a literal sense, by overwriting hooks like `_parallel_on_X_prange_iter_finalize`. In a literary sense an "agent" can be "that which is dispatched to" in order to achieve the desired effect.

@thomasjpfan Had a similar reaction when I mentioned it to him, so perhaps it doesn't clarify things as much as I thought 😅. Happy to discuss alternatives.

Labels: Documentation, API