Store marker color as a layer attribute instead of a source attribute

[mfisher87]

Currently all other style information is stored as attributes on the layer rather than the source. Markers are I think the only exception to that rule. Thoughts?

[martinRenou]

Agreed! @gjmooney would you be able to look into this?

[gjmooney]

I'm gonna say no to this

1. The color gets set on the style for the Icon which is really just a Feature, and Features are part of the source not the layer
2. The VectorLayer forms already hide the color field, so we'd need to special case Markers in vectorlayerform.ts to display it
3. If we do that, changing the field now triggers the sharedLayersChanged signal instead of the sharedSourcesChanged signal, so we'd also have to add special handling in _onLayersChanged to trigger a source update for marker sources.
4. Our sources aren't aware of their associated layers at the schema/file level, so there's a mapping saved in 'MainView' but that mapping obviously can't exist until the layer and the source exist. When a file is opened, sources get handled first, so when the marker source is created, there's no way to get the color info from the associated layer, since that association doesn't exist until the layer is handled.

[mfisher87]

You all know this codebase much better than me, and I'm not fully up-to-date on these specific changes, so I'd like your thoughts on what comes up for me when I read the above! This is not meant to suggest that I think we should go forward with this change immediately, as I feel certain architecture concerns will make that difficult.

1. When you say "Feature", do you mean openlayers feature? I'm wary about our schemas corresponding to openlayers-specific design! If/when we change renderers, I think we should architect in a way that the impact is limited to an adapter layer instead of needing to change our schemas.
2. This is a smell to me that our schema and form generation can use some design work. Instead of having our form-generation react components hide certain hardcoded fields, the information about what should be hidden could be embedded in the schema.
3. I think this is something we should decide is OK -- when we design our schemas, they shouldn't be locked in to the design of our renderer, so sometimes we may need to accept that a change in our layer schema will lead to a change in a renderer object other than a layer. I think an architecture which maps our own schema design to renderer design (adapter pattern) would help with this and simplify our codebase.
4. When you say the mapping can't exist until the layer and source exist, do you mean until they exist as OpenLayers objects? In Support divergent color ramps #912 we also had the need to lookup a layer's corresponding source before they both existed as openlayers objects, so we moved from a static mapping to a dynamic lookup in the shared model, and that enabled us to use information in the JupyterGIS Layer to update an OpenLayers Source: https://github.com/geojupyter/jupytergis/pull/912/files#diff-d610e45bb2cb68b897b52b1cb7e651ed8dbc8088d8f544fa5f0d4d8285ae4441