PR summary

Closes #29439, adopting the no line policy as described in this comment, we force all infinite, NaN and negative values of linewidths to 0.0.
For uniformity, ideally all linewidths(like hatch linewidths) should be sanitized in a similar way

Previous Behavior when passing NaN

• AGG - Sets lw = 0 after a perceivable lag:
  • In Renderer::Agg_draw_path, mpl_round is called on linewidth which successfully casts a nan value to an int (through mpl_round_to_int) which becomes INT_MIN (-2,147,483,648). Now the linewidth is a very large negative number.
  • render_scanlines() in agg_renderer_scanline.h calls rewind_scanlines where m_scan_y is set to -8,320,836 (An overflow safe version of INT_MIN used in rasterizer_cells_aa<Cell>::line). INT_MIN is shifted by 8 bits essentially dividing $-2^{31}$ by $2^{8}$ giving $-2^{23} = -8,320,836$
  • This m_scan_y value is incremented in the sweep_scanline() function slowly until it hits 0
  • In the meantime no line is drawn as num_cells is 0 each time sweep_scanline is called
• PS - Sets lw = 0 (Similar casting of nan to int causes undefined behavior)
• SVG - Sets lw = 1 (According to the docs, any invalid line like setting a nan linewidth in the CSS is ignored, defaulting to 1)
• PDF - Throws an invalid value error

Current Behavior when passing NaN

All backends draw no line

PR checklist

• "closes [Bug]: np.nan in PolyCollection linewidths causes huge performance penalty #29439" is in the body of the PR description
• new and changed code is tested
• Plotting related features are demonstrated in an example
• New Features and API Changes are noted with a directive and release note
• Documentation complies with general and docstring guidelines