scatter() should not drop data points at nonfinite coordinates #12801

Currently, scatter() completely drops data points at nonfinite coordinates from the PathCollection it builds:

fig, ax = plt.subplots()
x = [0, 1, np.nan, 3]
y = [0, 1, 2, 3]
c = [0, 1, 2, 3]
pc = ax.scatter(x, y, c=c)
print(pc.get_offsets())

results in

[[0. 0.]
 [1. 1.]
 [3. 3.]]

i.e. the [2, nan] point is not recorded anywhere, even though we could just as well keep track of it and let the renderer do the job of not rendering nonfinite points.

As a result, this makes event picking less-than-optimal: adding

fig.canvas.mpl_connect("button_press_event", lambda event: print(pc.contains(event)))

to the code above, one sees that the first point is picked at index 0 ((True, {'ind': array([0], dtype=int32)}) is printed when clicking on it), the second one at index 1, and the last one at index 2. So one cannot use the resulting index to lookup into x/y/c, one has to index into pc.get_offsets()/pc.get_array(); and if one wants to index into some other array (my actual use case), one needs to manually count the nans in x/y/c and do the index conversion.
As a comparison point, Line2D does keep invalid points around and lets the renderer kill them.

Likewise, points with nonfinite values are dropped:

pc = ax.scatter([0, 1, 2, 3], [0, 1, 2, 3], c=[0, np.nan, np.inf, 1])

results in behavior similar to the one described above.
In this specific case, I actually think nonfinite points should respect the colormap's colors set by set_under/set_over/set_bad (right now they don't, they are again wiped out of existence) -- after all that's exactly what these "extra" colors are for.

This second issue (invalid c) has already been reported elsewhere and there are already PRs for it: #4354/#9891/#12422.

mpl master/3.0.2
Arch Linux/Py3.7