We can afford a slower performance in this parsers with python2 to
keep compability with python3.
http://sebastianraschka.com/Articles/2014_python_2_3_key_diff.html#xrange

       Juha Niskanen  committed 326ab01 2017-06-20
         STM32 F7: Set I2C4 SDA and SCL pins to open drain mode

       Titus von Boxberg  committed f3267dd 2017-07-17
         I2C4_SDA can also be on GPIO PB7

      Titus von Boxberg  committed 28eab90 2017-07-27
         No FSMC, only FMC for STM32F7

Because it's only used for missions

Useful to see when a in-flight mission update happens from the log.

and thus the current _mission_type does not matter.

- avoids race conditions when geofence data is updated in flight. During
  a transfer, the geofence module will not check for violations, which
  is done with the new dm_trylock method.
- there is an update counter stored in dataman, and for each write
  transaction this is increased, so that the geofence module can reload
  the data upon data change (after it's unlocked).
- single dm item updates are atomic already, so resetting the polygons
  to 0 does not need locking.

and remove duplicated output, mavlink_log_critical already outputs to the
console

We'll use dataman to check for geofence data updates.

directly mapped to the posix method sem_trywait

It currently cannot be configured via mavlink mission protocol.

Since the altitude is not used, we can ignore this as well.

Since vertex_count is in a union with do_jump_current_count, we can't
always reset the current count, otherwise the vertex_count ends up being
0.

This also removes the 'navigator fence <lon> <lat>' command to simplify
code (I don't think there's still use for that anymore). However the
file loading is still supported.

If goefence.txt does not exist, navigator will not clear the geofence
anymore on startup.

... and init to 0 is not needed, since already done in constructor

- retrieve & store the geofence & rally point data from/to dataman
- interleaved transmissions (of different types) are not possible. trying
  to do so will NACK the new transmission
- only one storage backend for polygons & rally points (not alternating
  between 2 as the mission does)

- orb_advertise already publishes a struct, no need for orb_publish
- mavlink_log_critical goes to the console too

- this was never read
- it was implemented wrong, leading to memory access violations in
  publishFence (an integer was passed instead of the fence_s struct)