QtLocation: start using Pointer Handlers and get rid of the C++ gesture recognition logic

We feel the need to do this to prove that Pointer Handlers are done. There should be suitable handlers for all of the gestures that maps actually need.

I made a naive attempt here to rip out everything and start over: https://codereview.qt-project.org/#/c/221725/ but found some issues. A big one is that QDeclarativeGeoMap has

Q_PROPERTY(QQuickGeoMapGestureArea *gesture READ gesture CONSTANT)

that is, QQuickGeoMapGestureArea (the very thing we are trying to get rid of) is part of its public API. So, unless we can get rid of that (which would break many applications), we have to keep it working... so it seems that to use Pointer Handlers, they must be programmatically instantiated inside. We can use them to do the work, but we have to keep QQuickGeoMapGestureArea's public API working too.

This implies that Pointer Handers need to have public C++ API to make such things possible: and it's a good way of verifying that the C++ API will be useful, too. Perhaps Qt Quick Controls could later on make use of the same C++ API. But this is a lot of work, and is not yet started.

The other big issue I noticed is that the map item is not just a map renderer which can be panned inside a Flickable for example. It actually only renders the part of the map which should be visible. Therefore it will not work to let DragHandler try to drag it around simply by changing its x and y coordinates like we're doing in FakeFlickable. So maybe we have to set `target` to null, and in a slot connected to translationChanged, convert the pixel-based translation vector to a geo coordinate offset, and ask the map to recenter there. Or something like that. What I tried to do is make the map render 3x as big in each direction so that you can always drag it within the bounds of the viewport (and then it re-renders when you release the point), but that wastes more memory and CPU power, and does not allow extreme pinch-zooming either.

All in all, I think the map item is not architected to be a good "do one thing and do it well" component; and because of having public API, we can't change it too much either. The way I see it, rendering maps should be based on some sort of reusable tile-rendering item whose size in pixels is as big as the whole map, but which somehow gets informed of the area within that which actually needs to be rendered. (It should be reusable for Table, too. TableView has the same problem, that it does too much internally rather than just managing the rendering of the cells and leaving everything else up to other components.) Maybe you have to subclass it in C++ to write the tile-providing logic. You end up with an Item that simply renders the relevant part of the map, and has no other responsibilities. Then, you put it inside an Item which is used to clip it, and which also hosts the PinchHandler, the DragHandler and so on. (The same architecture as FakeFlickable.) Those manipulate the map item's coordinates and scale. It would be much more modular, much easier to compose any kind of UI that you like by working better with the rest of QtQuick.

It has been said though, that because OpenGL uses float coordinates, not doubles, perhaps the pixel-coordinate precision is not good enough to do it that way. (At the maximum zoom level, how big is the whole world in pixels? How much land area does one pixel represent then? Can you still drag it by one pixel, or would it jump across larger distances when you try to do that?)