Avoid losing the OSM relation member type information

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.