Fix draw order for low-zoom amenity points

[kaneap]

Fixes #2431 Also partially addresses #3880 for low zoom amenity points.

Changes proposed in this pull request:

• fixes draw order for amenity features which start rendering at zoom levels 1-15 to render first if their min zoom level is higher
• Draws bus stop and bus station higher than other features which begin rendering at level 16 and higher
  As mentioned in Symbol and label prioritization is not in sync with the starting zoom levels #3880 manually working through the layers and adjusting the drawing order to match the order of starting zoom levels is maintenance intensive. However, given the relative low number of amenity points rendered at low zoom levels, and how rarely new ones are added or modified (the last time something was modified in these zoom levels was in January 2021 with De-emphasize parking=street_side #4301 as far as I can tell) this is not a big issue. This can also serve as a starting place for defining rendering levels in the SQL queries if that approach is ever taken (the second suggested approach in Symbol and label prioritization is not in sync with the starting zoom levels #3880)

Test rendering with links to the example places:

Bus stops now render above shelters:

Location: https://www.openstreetmap.org/#map=16/43.0436/-87.9453
Before

After

Cave no longer obscured by drinking water

A cave entrance (starting zoom 15) is no longer obscured by a drinking water tap (starting zoom 17) at zoom 17. Location: https://www.openstreetmap.org/#map=17/46.32509/9.42185
Before

After

Large tower no longer obscured by minor dish

A major radio tower (height 374m and starts rendering at zoom 14) is no longer obscured by a small communication dish (starting render zoom 17) at zoom 17. Location: https://www.openstreetmap.org/#map=17/43.11092/-87.92899
Before

After

[imagico]

Thanks for working on this.

This change as is seems to partially duplicate the zoom level logic from amenity-points.mss inline in SQL code in project.mml with a CASE statement. I have not checked if it does so accurately but i will assume for the moment it does. The starting zoom level in SQL is used to order the features in rendering while the actual filtering of what is shown at what zoom level is done in MSS based on the separately implemented logic there.

This is indeed the simplest way to approach what i suggested in #2431 (comment). However, this would ultimately mean duplicating the whole zoom level logic from amenity-points.mss into SQL. This is not desirable i think. As explained in #3880 (comment) - if you have the starting zoom level in SQL already there is no point to also have it in MSS in addition. Instead you can do the filtering in SQL as well. Apart from this duplication issue this seems in principle a viable approach to address #3880.

Personally i would not be in favor of trying to address #3880 by inlining the zoom level logic in project.mml. I would rather go the route sketched in #3880 (comment) to generate the necessary SQL code via script from a formulation of the zoom level logic that is designed for maintainability and scalability (allowing us in particular to better manage #3635).

Since @pnorman has in the past been opposed to all suggestions made to modularize SQL code of the style i would like his opinion on this and what he considers the best way to address #3880.