Always use polygon with holes primitive for drawing polygons, as this
should be faster than older SDL_gfx like drawing primitives because
we do not copy the coordinates into different style buffer before
raycasting.

This adds multi polygon support to navit binfile.

It uses the following attempt:

 -  Multipolygon "outer" polygons are converted to polygons inside the binfile map.
 -  Multipolygon "inner" polygons are added as attributes to the outer polygon.
 -  New method is added to graphics to draw polygons with "holes" (currently qt5,
    gtk_drawing_area, and Windows (except CE) but at least sdl can do this as well)

Since the binfile format stays structural intact, new maps can be processed by old Navit versions, except they draw the multipolygons without their "holes",
New version of Navit can still read old maps of course.

Limitations:

 -  In the maps, there are multipolygons having other multipolygons as inner or outer.
    These are unsupported and fail the member check. According to 
    https://wiki.openstreetmap.org/wiki/Relation:multipolygon these are invalid. And the
    current web display cannot display them as well. See
    https://www.openstreetmap.org/relation/5587300 . Don't know if this get a standard
    mapping feature. Hopefully not.
  - Multipolygon polygons tend to become huge. No algorithm to split them into smaller
    chunks is contained. But my personal opinion is to exclude some types of polygons
    from map altogether on constrained devices over not including or artificial cutting the
    multipolygon ones. Btw. there are already huge traditional polygons as well.
  - Processing the map required more disk space as one cannot early drop ways with
    unknown tags any more, as they could be part of multipolygon. Maptools -n flag
    works as expected for the final result though.

Additional changes:
  - Default to 64 bit zip files on maptool

Fix:xml:Fix bike routing