Split OSMGraphBuilder, support for unconnected P+R areas (#1562)

This is a first step in taming the OSMGraphBuilder monster. I did not wanted to make it bigger by fixing #1562, so I moved around the code a bit before adding new functionnalities. OSMGraphBuilder line count goes down from 2850 lines to 1100.

### Changes
- Area, AreaGroup, Ring inner classes are now first class citizens. The classes were rather independant anyway.
- The "walk area visibility" code moved to a dedicated helper class. The interface is not optimal but as this code is meant to be reworked we can live with that.
- Created a OSMDatabase to store OSM various stuff (nodes, ways, areas, etc...) with handling of area generation.
- Moved some utility functions to OSMFilter. Maybe this could be merged with some functions in OSMNode/OSMWay/OSMWithTag (various isSomething() functions).
- Fix #1562 by adding virtual OSM nodes at way/area intersections (at the same level).

### TODO
- Remove the Handler inner class of OSMGraphBuilder, it's not really relevant anymore.
- Really refactor the whole stuff (by better encapsulating OSM data manipulation from the rest for example), because all those changes are not really refactoring, just splitting/moving code around.
Thanks for your comment.
That could be a nice idea indeed. What could be done also would be to uncouple OSM data building (handling relationships, dependencies, area building, intersections...) from it's domain-specific usage (read: OTP). I'll be writing an email to propose something. But it would be quite a lot of work...