The idea of using a container object for streamplots was discussed in#803, but they settled on basically a lightweight datatype object. My reasoning for switching to a container was a combo of container providing a nicerrepl (kind of) and so that there would be more uniformity around artist return types cause the docs can all point to.Container

I'm sort of concerned that no tests seem to fail given the discussion in the original PR is that containers don't play well with scalar mappables, but that could be due to changes in how container was implemented?

This came up cause of the discussion in#24274 around good examples forArtistAnimation being the artists that return containers or contourset. Looking at contourset, that seemed very specialized and like it made more sense to think of this like the containers and maybe build out to support some of the other things mentioned in the note for this method.

The actual change is super lightweight since it's switching one named tuple for the other, which means anyone currently relying on a StreamplotSet object doesn't lose thelines orarrows attribute.

It seemed easiest to weave this in is by

1. deprecatingStreamplotSet
2. addingStreamplotContainer

I didn't write up a whats new or api_change 'cause I know this needs to be discussed first.

Eta:@efiring what sorta information did you want this container to hold?