Instrument PatternStringProperty and DerivedProperty for strings that need to be autoselectable in Studio.

[pixelzoom]

#178 resulted in a bunch of new DerivedProperty instances that dynamically create strings that appear in the UI. Per https://github.com/phetsims/phet-io/issues/1942, they will need to be instrumented for PhET-iO. And per phetsims/fourier-making-waves#235, we need to decided where they live in the Studio tree.

[pixelzoom]

There are no PatternStringProperty in this sim, so just DerivedProperty.

[pixelzoom]

This is on-hold, pending resolution of 2 issues:

• Instrument PatternStringProperty and DerivedProperty for strings that need to be autoselectable in Studio. fourier-making-waves#235, in which we're deciding where derived strings live in the Studio tree.
• https://github.com/phetsims/phet-io/issues/1943, in which we need a subclass of DerivedProperty for this purpose

[pixelzoom]

For this sim, I'm going to take a different approach than phetsims/fourier-making-waves#235. I'm not going to instrument the RichText markup that is added to math symbols (the Properties in GQSymbols.ts). Those cases add the most "nesting" to dependencies, and seemed to be the least useful in Fourier. I've noted this a code comment via the commit above.

The result of this decision: strings that appear in the UI and contain symbols are not autoselectable in Studio. The set of symbols is: a, b, c, h, k, p, x, x², y

@arouinfar please review in Studio and let me know how this feels.

@zepumph @samreid FYI.

[arouinfar]

Thanks @pixelzoom. As expected, there is quite a bit of text that is not autoselectable, but it all pertains to equations and related coefficients. The experience does not seem buggy, and I think it's easier to direct users to things like aStringProperty rather than have them traverse nested dependencies. I'm tracking examples in #189, so we can close this issue.