PR summary

I accidentally introduced a regression in#29399, which broke wireframe plots when there are an unequal number of rows and columns. That case forms ragged data which can not be concatenated into a single numpy array. This fixes that, and adds an image test. But the fix isn't ideal, and there are a few different paths we could take:

1. The current solution of creating an array large enough to hold both differently-shaped row and column arrays introduces a potentially large number of NaN points in the returned Line3DCollection, which might be an issue for users that then postprocess this data.
2. An alternative would be to generate and return separate Line3DCollection's for the rows and columns, but that changes the return signature.
3. Potentially we could modify Line3DCollection to handle groups of several collections internally? Seems messy though.
4. We could also partially revert the previous PR and return to ragged lists for this data, but lose the vectorization / draw speed improvements.

Note that this issue isn't present for other collections such as Poly3DCollection because those do not plot a higher density of data on the lines in-between grid points like Line3DCollection does.

There is also a performance improvement here. In the previous PR I identified the autoscaling of the axes as a large time sink, but didn't realize that there was lower hanging fruit. Instead of autoscaling based on all the X, Y, Z data passed in, we now only autoscale based on thevisible data. For my example test of a 4000x4000 wireframe at the default rstride, cstride = 50, this reduces the data parsed for autoscaling from 3x4000x4000 to 3x4000x100. There is a slight change in behavior in that axis limits will no longer bound data which are skipped over between lines, which changes one of the baseline image tests.

Before, majority of plot time (3.5 seconds) dedicated to autoscaling:

After, 20milliseconds dedicated to autoscaling:

PR checklist

• [n/a] "closes #0000" is in the body of the PR description tolink the related issue
• new and changed code istested
• [n/a]Plotting related features are demonstrated in anexample
• [n/a]New Features andAPI Changes are noted with adirective and release note
• Documentation complies withgeneral anddocstring guidelines