[FEATURE] Limit queries to specific feature types

[Mashin6]

Implementation of this is dependent on #255.

Currently each query is run on all three types of objects node, way and relation written as three separate lines. There is only one way how to change this and that is with opq(..., nodes_only = TRUE) that sets an attribute in opq object. If #255 gets implemented I could imagine adding another parameter that would specify type of objects.

get_osm_features(match_all = c("natural = tree", "leaf_type = broadleaved"), type = "n")

Possible type values and their translations:
n: node[natural=tree][leaf_type=boradleaved];
w: way[...
r: rel[...
nw: nw[...
nr: nr[...
wr: wr[...
nwr: nwr[...

This will be stored by get_osm_features in new opq$type slot. Length of $type has to match length of $features.

[mpadge]

Addressing this would also require finally thinking about the by-now-four-year-old #55. In principle at the overpass side, each of these combinatorial possibilities (so from nw down) offers the possibility of recurse down. They all offer the possibility of recurse up, as well as simply queries with no recursion. So implementing even #55, let alone this one, opens up a truly bewildering array of possibilities in place of current form which offers no such options but a compelling simplicity in place of this.

This simplicity was a very large part of the initial motivation for the package, and not something we would want to compromise. That just means that, if this were to be implemented, it would need to be done in a way that was as nonintrusive as possible, so nobody who didn't care about this would have to.

And now the even bigger issue: The current "always-recurse-down" implementation ensures that all queries return sensibly complete spatial objects. Embarking upon any of these options opens up the possibilities of returning objects that make sense in the OSM domain, but which are difficult to convert into Simple Features format. I personally don't have any great issue with that, and would love a world in which everybody was happy with sc instead of sf, but that's not the world we have, and I'm sure the vast majority of osmdata users use osmdata_sf. You can't covert a raw relation into a spatial object, and without recursion, it's equally difficult to convert many of the other possibilities. All just means that, like #255, this needs some very careful thought and design before proceeding. But thanks for starting the discussion, and it will be interesting to see where these considerations take us.

[Mashin6]

I think it is totally possible to keep it simple with good defaults.

1. If the default type is set to nwr then user would write the code as now get_osm_features(key= , value=) without knowing what is going under the hood. But if someone wants only dams that are line features (not nodes, relations), it would be as easy as setting a different value for type get_osm_features(key="waterway" , value="dam", type = "way")

2. Recurse-down: this is a separate issue. Filtering by type would not mean that only those type of objects will be returned by overpass, but that from all 3 possible types only e.g. ways tagged waterway=dam. But to reconstruct those ways we will still need to use recurse-down to obtain nodes that compose them. So recurse-down should always be default.

3. Recurse-up: This is used to obtain all features that are comprised of queried object. But to get geometries, we still need to recurse down. So again recurse down (._;>;); is a default. And recurse up could be a function e.g. get_parent_objects() that would include recurse up <; part.
   e.g.

opq_osm_id (type = "node", id = 243398687) |>
     get_parent_objects() |>
     osmdata_sf ()

[out:xml][timeout:25];
node(id:243398687);
<;
(._;>;);