Evaluate "centralized code with options" vs "extendable base classes" for this sim

[samreid]

While implementing #149, it seems the sim is more based on options and having parent types implement things (like the accordion box), but this is making it difficult to adjust and customize for the Variability screen. For instance, we need to add different checkboxes, an info button and move the left edge to the right. Should all of this be through options, or should the VariabilityScreenView create its own CAVAccordionBox that it customized appropriately? I want to discuss this with @marlitas and/or @matthew-blackman before working on it, because there are tradeoffs either way and it would be good to discuss before spending a lot of time on it.

[samreid]

This issue has some overlap with #152

[samreid]

I feel the last place where this issue applies is in the readouts on the left of the accordion box for screens 2-3. @marlitas was working on that, I believe.

[marlitas]

Completed the readouts in accordion boxes. Over to @samreid for review, and perhaps closing this off together.

[samreid]

Commits above look good. The proposed changes in #170 also match this pattern. I feel this issue can be closed.

[phet-dev]

Reopening because there is a TODO marked for this issue.

[samreid]

All TODOs addressed. Ready for review. In my opinion, I feel there are still some places that could use refactoring like this, but we can address them if/when discovered. @marlitas can you please review recent commits and close if all is ok? Or comment if you know of other places that should be refactored?

[marlitas]

Reviewed with @samreid. Any other work regarding this topic will be done on an as-needed basis. We are ready to close.