Design logic for when to show the grab and drag cues

[zepumph]

Originally reported in #354, and design meeting done in #354 (comment).

Today @DianaTavares and @samreid and I had a conversation where we didn't like treating individual blocks as separate, because you could get into cases where one of five blocks had been grabbed, and four of five blocks were still showing the grab cue.

Instead, let's try out this design:

• treat all "mass types" as the same per screen.
• The scale, if moveable, is never the same mass type as other masses.
• On compare screens and two block screens, all blocks are the same mass type
• On shapes screen, all shapes are the same mass types for both A and B.
• On Applications screen, the boat/bottle/block are three separate mass types.

Note that we also want this exact logic for the drag cue (see #364) as well, and we can update these independently in the future if needed.

@samreid also mentioned that another idea would be to never assume that we know when to hide an interaction cue, and instead have a preference that a user can use to hide it. @zepumph wonders if a hint to tell the user about the preference may help this design.

[zepumph]

I'll do phetsims/scenery-phet#867 as part of this.

[zepumph]

phetsims/scenery-phet#867 has a GrabDragModel() Prototype for us to use now.

[samreid]

I shared the appropriate GrabDragModel instances between the related Mass instances. I added code comments for the rough edges. For reset, I recommend that Mass.reset resets the given GrabDragModel (don't try to have some of them skip that step and do it at the shared declaration.) This is ready for code review.

[samreid]

@zepumph added some simplification in the commit, and we will continue in phetsims/scenery-phet#867, closing.

[zepumph]

Let's check in with designers and see how they feel about this, but before we do this, we will want to wait until we have drag cues in #364.

[zepumph]

Ok. Let's discuss with designers now that #364 has made progress.

[zepumph]

At design meeting, we decided that we like this design as it is implemented now:

• Treating a single cue per object "type" (all blocks on a screen).
• We like hiding the grab cue upon first grab.
• We like hiding the drag cue node upon first drag.

These follow precedent from BASE and Friction. In the future, as we learn more from interviews, we may change the cueing logic more generally.