Beautification of Proxies

[NiklasRentzCAU]

We now have the basic support for proxies in this repository. However, there are still a few changes that should be implemented before considering proxy

Edge Proxies:

• Removing single routing points from splines makes them appear in unexpected ways and lets them jump around a bit (as the rendering does not know how to interpret a Spline with an incorrect amount of bend points, therefore it draws a spline and does its best effort to connect the remaining bend points as a straight line). This could be fixed by first looking if the line is a bend point and then only modify/remove the bend points in sets of three. The very first bend point is always the start point, the next sets of three are always two control points and a third one where the edge actually goes through, see for example here.
• Edge proxies from an off-screen node to a partially on-screen node, where the attachment point is still off-screen causes the edge to be drawn across the node proxy. I think such an edge should not be drawn in the first place.
• An on-screen edge with both source and target off-screen could also connect to their proxy nodes
• the selection filter should also show proxies if the selected element is an edge or a port, not just if the selected element is a node (current impl.)
• The along-edge bend points should do a nicer layout to route the edge around to its connection point on the proxy instead of doing the current diagonal line from the last bend point on the border directly to the proxy attachment point. This sometimes causes the edge to overlap the node proxy.

Node Proxies:

(this is referring to "signpost" proxies as proxies positioned where edges leave the screen, so that the proxies work as a "signpost" showing where the edge going off-screen is headed to without needing to do edge-proxies for that)
To create a "signpost" projection of proxies onto edges (if they are on-screen), the way proxies are created and positioned has to be modified. In proxy-view.ts the method getTransform is responsible for positioning a node's proxy. The current structure only creates a single proxy for such any node. In a signpost projection we would require more. Additionally it needs to decided how to handle nodes where there currently is no connecting edge on screen. The simplest approach would be to not create a proxy in that case. But we could also use a radial projection for those nodes. Going further it might make sense for the synthesis to be able to specify using semantic tags, which projection should be used.

Spline intersections: https://scholarsarchive.byu.edu/cgi/viewcontent.cgi?article=1000&context=facpub chapter 7

De Casteljau's Algorithm

General

• The proxy options should then not be debug options anymore so that anyone can use and configure them!
• There are quite a few eslint-disable-next-line statements in the new code, this should be refactored.
• proxies do not work in combination with top-down layout. They are just shown in the bottom left corner, where the original nodes would have been placed without top-down scaling.

[NiklasRentzCAU]

More issues found while using proxies, collected in this issue:

• When panning in the view and just panning the container of proxies out of view, so that they should disappear as well, the console might throw this error: Error: <rect> attribute width: A negative value is not valid. ("-3") stemming from proxy-view.ts in the update method, where the currHTMLRoot gets set by the patcher.