Refactor restriction parsing to consider all tags on a relation

[karenzshea]

From #2802 (comment)

Today in some circumstances (restriction=no_* lead to false and then restriction:<>=only__ leads to true) the last restriction value of type only will override the previous ones regarding the variable is_only_restriction (which will be set as true). With this patch it will be even more visible and the last restriction will always override is_only_restriction. To solve this already existing case will require some additional steps/a rewriting of the whole algorithm. But at a first step and to close this issue ignoring the second if and adding only the else statement will solve the current issue (i.e. ignore not-supported restrictions) without changing the existing behavior.

Turn restriction extraction currently has some "last processed restriction wins" logic. My understanding is that in a scenario where a relation is tagged with both a restriction=no_turn and a restriction:bicycle=only_right_turn, if the restriction=no_turn is looped over last, the relation will be understood as a restricted turn, even if it's actually a valid turn for bicycles.

Solution would be to holistically consider tags on a relation to determine a restriction for the given profile.

[daniel-j-h]

I think the issue actually goes deeper. We handle all tags prefixed with restriction as in restriction*= instead of only restriction=, have a look at the KeyPrefixFilter here:

osrm-backend/src/extractor/restriction_parser.cpp

Lines 66 to 67 in 6fac14d

	osmium::tags::KeyPrefixFilter filter(false);
	filter.add(true, "restriction");

This has to change completely based on the profile we're using if we want to support restriction:<type>= tags.

Quick fix is to change the KeyPrefixFilter to a KeyFilter.
And only support restriction={no_,only_}*.

Seems like there are not that many restrictions following this scheme anyway e.g. for the tag in question restriction:bicycle: http://taginfo.openstreetmap.org/keys/restriction%3Abicycle