Extend LaneType with the ramp family — faithful since #476, still not usable or authorable

[JArmandoAnaya]

Split out of #476, which anticipated it: "Optionally (separate decision, not required for fidelity): extend LaneType with the ramp family so the mesher/panels treat them as drivable."

#476 made RoadMaker faithful to these lane types — it no longer rewrites them on save. It did not make them usable, and the gap is now visible in a way it was not before.

What the gap is

LaneType models 11 of e_laneType's values (§11.8.1). The whole ramp/merge family is outside it and parses to LaneType::Other:

entry · exit · onRamp · offRamp · connectingRamp · slipLane

Consequences today, after #476:

• Read faithfully, but inert. An onRamp lane round-trips byte-perfectly and is drawn, but every consumer that asks "is this drivable?" says no. driving_lanes_at (and therefore junction turn generation, edit::connection, and the maneuver set) treats it exactly like none.
• Cannot be authored at all. Lane::type_str is deliberately read-only from Python, and there is no LaneType value to pass — so a script can preserve an onRamp lane but cannot create one. RoadRunner authors these routinely.
• The properties panel shows "Other", and rebuild_choice_combo appends that as a synthetic entry. It is honest but unhelpful, and re-picking it is now guarded precisely because it used to destroy the spelling.

Why it is a real decision, not a chore

Adding the six values is mechanical. What is not mechanical:

1. Which of them count as drivable for turn generation. onRamp/offRamp/connectingRamp/entry/exit carry traffic; slipLane does too but bypasses the intersection, which is exactly the case junction generation would need to not treat as an arm.
2. Whether the mesher should style them differently from driving (it currently styles Other as unpainted).
3. bidirectional, also outside the enum, is deprecated by §11.8.1 in favour of @direction="both" — so it should not be added; it should keep round-tripping as Other and ideally warn with that advice.

Scope

• Extend LaneType with the six values, and update every switch the compiler flags (-Werror=switch makes this enumerable rather than guesswork).
• Decide and document the drivability question above; docs/domain/opendrive.md is the place.
• kTypeChoices in the properties panel, and the Python enum binding.
• Round-trip stays byte-identical — xodr: unknown enum spellings are rewritten on save — lane type → "none", road-mark type → "solid", colour → "standard" #476's tests already pin the spellings, and the ones that move from Other to a real enum value must keep writing the same bytes.

Acceptance

• An onRamp lane authored from Python writes type="onRamp" and reads back as the same enum value.
• core/tests/fuzz/corpus/foreign_enum_spellings.xodr still round-trips byte-identically (its onRamp/slipLane lanes now parse to real values rather than Other — the bytes must not care).
• The documented drivability ruling has a test per value.