Volker Krause authored Oct 02, 2020 and Torsten Rahn committed Oct 11, 2020

There seems to be the assumption in a number of places here that a single
64bit number is enough to identify any OSM element. This however isn't
entirely correct, as OSM nodes, ways and relations use separate identifier
spaces, so we either need to infer the type from context or explicitly
carry it along next to the number. This wasn't done for non-geometry
relation members however, resulting in all member types ending up as "way"
when serialized back to o5m, which quite thoroughly corrupts those
relations.

This change does the bare minimum to fix this specific issue, API not
relevant for this is adjusted to keep the old broken behavior.

With relation member types preserved we however hit a subsequent problem
in the o5m encoder, which needs to track differential id encoding state
separately per type.