Introduce OsmModel and cleanup GeoUtils

[johanneshiry]

Close PR of #133 first

The GeoUtils are not tested nor properly implemented at the moment. Furthermore, it would make sense to have a specific OsmModel in order to be independent of third party libraries.

• Close PR of Add a scala package to include scala utility classes and methods #133
• Design an OsmModel #158
• Adapt the existing GeoUtils to account for our own OsmModel #163
• Write tests for the affected methods

[larslenssen]

I would like to discuss the structure of Relation and trait Way in OsmModel.

Is it necessary to store a list of nodes, is it not enough to store a list of IDs? Otherwise we will have duplicate information stored in the model. We could also consider numbering the nodes independently in ascending order. This way we could store the nodes as an array and access them faster.

Let's discuss!

[t-ober]

I don't think we have duplicate information now as the nodes that are stored in the Way aren't a copy of the Nodes themselves but a reference to the same object. Not sure why we would explicitly number them as they have an associated index when being stored within a Sequence. If accessing a specific node somewhere in the list by their index is a usecase (although I'm not quite sure why) we should store them in a Vector rather than in a List (as Lists in Scala are implemented as linked list so accessing an by index is quite expensive). If we end up looking for specific Nodes (via their uuid or osmId) we should consider keeping a Map[UUID, Node]