Migrate GLR to metarules

[memo33]

'tis a beaut.

This replaces the old draggable GLR code by a rock-solid purely metarules-based implementation.

This PR depends on #557.

The old handwritten GLR code had some flaws:

• The orthogonal piece often switched orientation in the direction the network was dragged, which can lead to instability.
• The GLR code hadn't been kept in sync with changes to the Lightrail rules (such as the removal of the traffic circle from a four-way intersection).

---

Ideas for future extensions:

• add IDs for end stubs
• add support for Lightrail × GLR

These would require some work on textures/paths/models.

[jflann]

I don't recall if this worked under the old implementation. Is this something that should be handled by dll-based adjacency?

[memo33]

Yes, this used to work. So far, the Lightrail stubs were overridden by plain straight GLR pieces. Back in the day, this made sense for compatibility with stations for non-draggable PP-based GLR. The DLL-adjacencies don't cover this currently, mainly as a safe-guard against unintended stuff like recursion. The cleanest solution would be to introduce unique proper end stubs for GLR. Then the DLL would cover it. In any case, the stubs are more for a nice feel than they are practically relevant.

[jflann]

Yes, this used to work. So far, the Lightrail stubs were overridden by plain straight GLR pieces. Back in the day, this made sense for compatibility with stations for non-draggable PP-based GLR. The DLL-adjacencies don't cover this currently, mainly as a safe-guard against unintended stuff like recursion. The cleanest solution would be to introduce unique proper end stubs for GLR. Then the DLL would cover it. In any case, the stubs are more for a nice feel than they are practically relevant.

Okay, thanks for the explanation. I agree, the best way to resolve is to implement the end stub. I can look into that. It's definitely fine as is though.

[jflann]

Is this still required? AFAICT, there is no longer any handwritten GLR code.