travel mode

This branch is a port of the travel mode flag to the latest develop branch. There are still a few tests failing, but it should make it possible to asses whether the approach is viable.

The main use case of this feature is to be able to provide better instructions to the user, indicating when you need to push bikes, take a ferrry, etc. For bike routing, it's esential to indicate when users need to push the bike instead of ride.

The branch also solves inherent problems with the instructions enter_contraflow and leave_contraflow; when they were used, no information was passed about what direction to turn. With this branch, these two instructions are not used anymore. The travel mode is also more generel, since it can be used to indicate ferry, train, etc. or anything else that is useful.

Modes are represented by integers. 0 means no acces, while 1 is the default mode. Apart from that it's up to the profile to define how they are used. For example in a bike profile, you could use 2=pushing bikes, 3=ferry and 4=train.

In the lua script, you can set the mode:
  way.mode = 1
  way.backward_mode = 2

If you don't set it, it defaults to 1, so old profiles will keep working without changes.

Modes are stored internally using 4 bit for each direction (using bitfields).

When computing routes, each json instruction array contains an additional integer, which is simply the mode set by the lua script.

Initial measurements show no significant change in file sizes and processing times. Minor change is caused by changes in the bicycle profile, which was used for the test:

travel mode: https://gist.github.com/emiltin/f6b438854213a5359b89
develop: https://gist.github.com/emiltin/e6d759426e282af61f6c

Further space saving could be achieved by removing the 'direction' field in osrm structs, since this is fully indicated by the forward/backward modes.
Is this assertion failing? what does sizeof(NodeBasedEdgeData) say?