Stop plumbing osm_tags through

Road currently carries OSM tags. This is unnecessary to maintain through the whole library and in fact confusing as soon as we start merging/splitting/transforming roads. So instead, let's return a mapping from osm::WayID to the Tags from streets_reader for callers that want it. (And force callers to deal with roads possibly having multiple OSM way IDs.) Let's not store osm_tags in roads at all.

I did a cursory code review to figure out if this'll be hard or not. The changes:

We'll store a few new fields on Road. First the string highway type -- could be a sanitized enum later on. We should record the junction=intersection "should merge short" bit. We'll want the name and layer (for z-order); a few analyses need it.
Currently we hackily plumb through a fake abst:endpt_fwd and abst:endpt_back tag that can become proper booleans. These tell us if a segment of the road is the very beginning or end segment of a way. Looks like the only place this actually gets used is over in A/B Street's current code that generates turns from individual lanes. We use it to decide when to apply turn:lanes:forward and such. Temporarily we could plumb these two booleans through. When osm2streets handles lane-level turns/movements, we can drop this.

Most of the code changes are straightforward. A few of the trickier ones:

should_collapse for degenerate intersections compares tags between the two roads possibly being merged. It's a hacky comparison right now. I think we can just check name and derived lane specs. Technically we want to know if turn lanes differ... so maybe we ought to just add those into LaneSpec now, even if we're not using them?
transform/snappy.rs does lots of tricky stuff. This is an older and unused attempt at snapping parallel cycleways. I think we can ditch this in favor of the newer graph-based approach. (Still useful code to refer to for ideas, but that's what git is for)
is_light_rail and is_footway should look at derived lane specs. And also some of these look like they're only used by the defunct snappy.rs
LaneSpec::typical_lane_widths currently just uses highway and... apparently narrow=yes. For the latter, I think I added that as a temporary hack to try to make progress long ago in some specific and no longer relevant situation. Looking forward slightly, default lane width guess will depend on locale, highway type, and... yeah honestly that seems fine.

So, I'll go ahead with this, since I think nothing blocks it

Sound good to me! I'm in favour of putting lane turn restrictions in LaneSpec, that seems like the right place for it to live.

I thought I was done, but the test diffs are looking big. The trouble is

osm2streets/osm2streets/src/transform/collapse_intersections.rs

Line 67 in 3d64f99

    
           // Check what OSM tags differ. Explicitly allow some keys. Note that lanes tagging doesn't

. Previously a bunch of degenerate intersections were not collapsed, and with the change, they are. In some of the examples, the geometry is a big degradation. arizona_highways before:

After:

Root cause is https://www.openstreetmap.org/way/23806628 getting merged, now that smoothness differing between the two roads doesn't matter. But looking at this example more closely, the "before" is pretty broken, because the offramp physically overlaps the other road. The "after" looks funky, but it does "correctly" trim things to avoid overlap.

So, I'll look through all the tests carefully. It was an accident things looked differently before.

Aside: IIUC, placement would be helpful to tag and make use of for cases like this