Edge label positioning

[Wagner-Laranjeiras]

Summary

Fixes #514: edge labels positioned by a layout engine (e.g. ELK) were being
re-placed at the edge's geometric midpoint at render time, ignoring the
engine's coordinates.

EdgeLayoutPostprocessor now honors an engine-assigned position: when a
non-moveable edge label with no explicit edgePlacement carries a non-origin
position, its center is projected onto the edge (deriving the anchor and
tangent) and the existing rotation/alignment pipeline is applied. Labels that
were never positioned still fall back to the previous midpoint behavior.

The change is engine-agnostic (it reads the label's own model position, with
no dependency on sprotty-elk) and preserves rotation and edge-binding, as
requested in the review.

Changes

• packages/sprotty/src/features/edge-layout/edge-layout.ts: project the label
  center onto the edge for engine-positioned labels; extract the shared
  applyRotationAndAlignment helper.

Tests

• Unit tests for EdgeLayoutPostprocessor covering the fix, the no-regression
  paths (unpositioned/moveable/explicit edgePlacement), the origin sentinel,
  and the nested-nodes "free space" case.
• ELK integration tests asserting the engine assigns a non-origin position to an
  edge label, including a nested-nodes scenario where the label lands in the free
  space between containers rather than at the edge midpoint.

[gfontorbe]

Hi @Wagner-Laranjeiras , thanks for the contribution.

This is a good start. However the approach completely bypasses the post-processing if the label has been placed by ELK. This create the issue that rotation and bounding to the edge are not preserved (making every label "free").

Ideally this should also be layout engine agnostic and not depend on sprotty-elk

[Wagner-Laranjeiras]

thank you for your review @gfontorbe ! I worked on it. Here's the updated commit. 😄