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.