This also makes `NextRelation` return a tuple of ID, role rather than
just ID.

According to https://www.lua.org/pil/5.1.html, I think that's not a breaking change.

Motivation: When I naively try to create labels from OSM entities with the `place`
tag, I occasionally get duplicates due to relations.

For example, the city of Guelph has [relation
7486148](https://www.openstreetmap.org/relation/7486148), which has
[node 36576733](https://www.openstreetmap.org/node/36576733) as its
`label` member.

They both have `place=city`, so my Lua script faithfully spits out two
labels.

This PR allows me to suppress the label from the node, which is a start.

Ideally, I'd actually prefer to use the node, as it'll likely have a
nicely human-curated location. For that, I'd need the relation to be
able to interrogate its members.

Would you be open to me extending this PR to add `NextMember`,
`FindInMember` and `RestartMembers` functions that mirror the ones used
by nodes/ways ?

I dunno what I was thinking, this is much better. (And I see now that
there are many more roles than these four.)

Ugh, I guess this could be considered a breaking change after all.

If a user previously passed `LayerAsCentroid("layername", false)`,
we'd ignore the false.

With this change, the false causes us to fail, because we expect a
string.

I'd normally just say this was undefined behaviour, and those users
deserve to be broken...but it's tricky, since this is a script from the
official tilemaker repo.

These seems to work well and, at least for large polygons (city parks,
national parks), is faster than Boost's centroid algorithm. That surprised
me! I haven't benchmarked it on building polygons yet.

There are several todos here around making it configurable, and making
it play well with lazy geometries.

Going to finish off the relation memory stuff then fix those.

You can now pass the preferred algorithm to use to LayerAsCentroid.

Still to do: teach lazy geometries about which algorithm was used.

This ensures that the user gets the same, correct behaviour both in
--materialize-geometries and --lazy-geometries.

We can extend support to materialize geometries, but this PR is already
getting big (and it has conflicts with the other 2 PRs), so I'm leery of
getting further out over my skis.