Permit 'cycleway:both' way key to populate both left-and-right cycleway definitions

[jayaddison]

@Nate-Wessel @mjjbell I was taking a bit of a look at #6180 and the related test coverage question in the hope that it might be a quick fix / improvement.

A few hours later.. well, I'm not so sure it's a straightforward change, but thought I would offer what I've developed locally and some findings.

Usage of cycleway:both tag
I think that most of the increased usage of cycleway:both may be related to StreetComplete, a map editing app, which asks users about the presence of bicycle routes when they're providing map information.

If no bicycle routes are indicated by the user, the app will add cycleway:both=no -- and my best guess is that those entries account for most of the uptick in the graph that @Nate-Wessel referenced in the issue.

One-ways
One tricky edge case to handle is 'implied one ways' -- typically traffic-controlled motorways, roundabouts and on/off-ramps - places where cycling contraflow may be dangerous (and/or illegal). In those cases, the presence of cycleway:both as of f541885 currently short-circuits the one-way handling; each affected way will be considered as routable.

⚠️ This feels slightly unsafe, because those conditions could indicate a data entry or quality issue related to the implied one-way -- and marking them routable could cause real-world problems. Because of that ambiguity/risk, I think I'll open this pull request in 'draft' status pending discussion and resolution.

When using Overpass Turbo, an OSM query interface to try to find one-ways and motorways that have cycleway:both, I haven't yet found and confirmed any valid locations (after trying to compare against street photos -- and even then ground-truth checks would be a good follow-up).

Here's an example query I used, for reference:

way
  ["oneway"="yes"]
  ["cycleway:both"]
  ["cycleway:both"!="no"]
  ({{bbox}});
out;

Test coverage
This pull request offers some additional test coverage on various cycleway ... =no cases; these were partly to reassure me during experimentation and development, and partly because it feels worthwhile to reduce the chance that risky routing options could accidentally occur in future as the code evolves.

Resolves #6179 (alternate implementation to #6180).

[jayaddison]

Closing as stale.