Add color picker and choice of summary score style for wiggle track

[cmdcolin]

This adds a simple color picker for the wiggle track

This is almost going too far in a way, and I believe is starting to call into question the duplication of config items into state

I believe the user experience of having to clone a track and use our config editor is not ideal, and I think the track state and track menu helps, but it is causing duplication of code.

However, I also see that the continued use of track state as a way to open up a new opportunity: it offers a conceptually nice way to get config layers:I can simply say something like

// using concept from @teresam856 for top level config
getConf(getSession(self).WigglePluginSettings, 'someSetting')

Then I can get a "global setting" to apply to all my wiggle tracks a la config layers. This would be otherwise difficult to setup on every individual wiggle track

So there are tradeoffs here, but open to ideas.

Note that other track types like FeatureTrack could enjoy a color picker also

[codecov]

Codecov Report

Merging #1743 (0829b59) into master (a7a0a70) will decrease coverage by 0.06%.
The diff coverage is 10.34%.

@@            Coverage Diff             @@
##           master    #1743      +/-   ##
==========================================
- Coverage   58.73%   58.67%   -0.07%     
==========================================
  Files         455      456       +1     
  Lines       21049    21078      +29     
  Branches     4987     4990       +3     
==========================================
+ Hits        12364    12367       +3     
- Misses       8376     8402      +26     
  Partials      309      309              

Impacted Files	Coverage Δ
.../LinearWiggleDisplay/components/SetColorDialog.tsx	6.25% <6.25%> (ø)
...ins/wiggle/src/LinearWiggleDisplay/models/model.ts	69.05% <15.38%> (-3.33%)	⬇️
packages/core/util/index.ts	82.10% <0.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a7a0a70...0829b59. Read the comment docs.

[cmdcolin]

I tagged this discuss in meeting because of the duplication of config items in state. As noted above there are pros and cons. This was also brought up last week but the idea was that it seemed ok, but is there a point where it is too much

[rbuels]

What if we had a chained config-reading thing that looked like:

readConfObjectChain([config1, config2, config3], 'slotName', [args])

would return the first non-default in the chain, or the default if none set
would enforce that each of them is the same config schema

[cmdcolin]

Regarding the above comment, we probably wouldn't want to "validate that they have the same config schema" (because the top le vel config would not have track name, track description, track id, etc.) but it could be an option. However this would likely be a future thing (that may break sessions if we change a lot of things) because most of the track menu item logic is manual and involves normal MST state instead of config objects. The above comment might apply to a more advanced future config layers idea