Implementing turn costs

I've now partially integrated turn restriction and turn cost. @khuebner already did most of the work - thanks a lot! You can enabled turn costs via `osmreader.acceptyWay=car|turnCosts=true` or in java via `new CarFlagEncoder(5, 5, /*maxTurnCost see below*/3)`.

In order to do so I applied some changed which we should discuss:
 - to provide context for turn costs I added a new parameter `prevOrNextEdgeId` into Weighting.calcWeight. This avoids separate instanceof checks in all algorithms
 - I introduced "piping" of Weighting so the TurnWeighting now just holds another Weighting like for bike or car.
 - removed dijkstraNativebi as no performance advantage but maintenance disadvantage and similar to oneToManyDijkstra
 - removed TRAVERSAL_MODE.EDGE_BASED as I saw no benefit, so now either an algorithm is edgeBased or not.
 - changed the definition for costs vs. restriction: infinity == 'max cost' == restricted
 - currently turn restrictions for cars are disabled by default. We should probably change this.
 - fixed bug in OSMTurnRelation.getRestrictionAsEntries
 - defined weight to be in seconds not arbitrary for FastestWeighting to make adding of turn costs more meaningful (seconds!)
 - default u-turn cost is at 40 seconds but maybe we should completely avoid uturns as it increases search space? Also the only two applications for a u-turn I can think of are: 'tricking' turn restrictions and when via-points come into the game. Another minor problem is that we have to disable the performance tweak for edgeBased algorithms (`if (!edgeBased && iter.getEdge() == prevOrNextEdgeId) return false;`)
 - I implemented turn costs as well but only 2 bits (can be configured). I thought about the following sense: 0 (no costs), 1 (right turn), 2 (left turn?), 3 (forbidden). Also the bike and car encoder should make use of it (currently they don't, only restriction)

The following things are on my to do list before we can merge this branch:
 
 - [x] fixing #163 
 - [x] make one failing test pass in bidir algos (testCalcIfEmptyWay)
 - [x] compare performance with node based algos: nodebased still unchanged perf but horrible slow if enabled!
 - [x] make faster!
 - [ ] should we point from the 'from-edge' instead of the 'via node' to the turn information? As then we could omit the 'from-edge' and use the same turn information for the involved shortcuts too.
 - [ ] make dijkstraOneToMany working with turn costs. Hmmh, looks complex. We probably need findKey(fromIterationKey,toIterationKey) for CH instead of findEndNode and include all adjacent edges of the end points
 - [ ] enable turn costs for CH
 - [ ] improve performance
 - [ ] reduce disc size (e.g. excluding uturn restrictions or vlong storage), if there is a problem for world wide case (but probably not as only a few 100K relations)