Fix for regression with colorbar limits

[BioTurboNick]

#3839 solved a slowdown when re-rendering a plot for an animation, but reversed the benefits of #3838 for rendering the original plot.

This PR does two things:

• Only updates the colorbars once when a plot is added. Previously it was running twice.
• Stores the colorlimit values in a dedicated typed dictionary; storing them in the general properties dictionaries appeared to interfere with efficient code generation.

One area of concern: Are there other times when _update_sublot_args gets called outside of the pipeline, when the colorbar would need updating? If so, it would skip the colorbar updating routine.

Resolves #3873

[BioTurboNick]

Though I'm still curious why all it caused a regression at all... with #3838, plotting took less than a second, but it's 3 seconds currently. Because all that first PR did was add type signatures.

[BioTurboNick]

Got it down to 2 seconds by refactoring the if/else statement into functions.

[BioTurboNick]

I think the next frontier in performance improvement here is dealing with the fact that the clims calculation has to look at 4 different properties for each series. It doesn't seem to lead to any allocations but it does take a very long time run through them.

Especially annoying when they're all empty.

[BioTurboNick]

Alright! Unrolling that update loop got my big plot down to 1.5 s. Was 8 s before doing all of my recent profiling work.

Updating color bar limits is still a nontrivial amount of the computation time when profiling (50.1% of samples), but it's a lot less.

[BioTurboNick]

Tests are passing on my machine, so not sure what's happening here.

Oh, might just be related to the tick angle adjustments.