fix!: Normalize Zelos connection indicators

[gonfunko]

The basics

• I validated my changes

The details

Resolves

• Fixes Zelos does not support input outlines around filled inputs - causes preview weirdness #3659
• Fixes Provide connection previews when connecting a moving value block's input to an existing block (zelos) #9338

Proposed Changes

This PR cleans up Zelos' display of proposed connection indicators. Previously, proposed input connections indicators had three possible appearances:

Fuzzy, when an existing block would be replaced

Normal, when a block would be connected to an empty input

Skinny, same circumstances as above but when the highlight ring happened to be z-ordered below the fill for the input slot.

Likewise, next/previous connection indicators could appear normal, or partially obscured by the insertion marker depending on the whims of z-ordering:

Now:

• The "replacement fade" (fuzzy) filter has been entirely eliminated; the connection highlight for replacing a block appears the same as the highlight for inserting a block into an empty input connection
• Connection highlights are always brought to the front, so the skinny/obscured appearances are eliminated. This also normalizes them and makes them consistently prominent for Geras/Thrasos.
• Input connection highlights are shown in Zelos on both the dragging and stationary block, as appropriate; previously, if the block being dragged was aligned in such a way that it was eligible to connect to an input on a stationary block, there was no visual indication of this.
• BlockSvg.highlightShapeForInput() has been removed, as it was internal and had no callers.

Breaking Changes

• REPLACEMENT_GLOW_COLOUR, REPLACEMENT_GLOW_SIZE, and replacementGlowFilterId have been removed from Blockly.zelos.ConstantProvider. References to these fields should be removed; the appearance of the connection indicator can be styled with CSS targeting .blocklyHighlightedConnectionPath.
• IPathObject.updateReplacing() has been added; this method is optional and the root PathObject defines it by simply toggling a class, so this should not strictly be breaking, but custom renderers may wish to implement/override it.

[BenHenning]

I haven't looked at this in depth quite yet, but how are highlights now consistently brought to the front to fix the z-ordering issue, and does this introduce any problems with keyboard navigation? I remember digging into this before and I found that the standard bringToFront will break focus since it changes the DOM and many DOM operations just completely reset focus back to the document body. I think we built some resilience to this failure type in places (and maybe in FocusManager itself) but I would need to dig to confirm.

Edit: Ah, #8981 was the one that may have made this work. I'm still curious about the first part, though, because I don't see bringToFront used anywhere.

[BenHenning]

Other than my specific concerns on focus this seems like an excellent simplification.

[BenHenning]

This might cause focus loss problems. I'm also curious why this is necessary--shouldn't the highly SVG already be properly parented since it exists in the DOM at this stage?

Or is this the means to try and 'bring it to front'?

[gonfunko]

Yes, this is the means to bring it to the front. Experimentally, there don't appear to be any focus issues, I think because the highlight SVG is not itself the thing that has focus; I was able to move blocks using keyboard nav and Zelos and it behaved as expected.