gluon-autoupdater: get random number from /dev/urandom

The approach with awk's rand() wasn't really random between across
devices: When srand() was called without arguments, time() was used as
seed, which of course is the same on all devices when the script is
called via cron at HH:00:00.

This patch instead uses /dev/urandom as source of random (we don't need
cryptographically strong random numbers, so urandom is just fine) but
still uses awk for the comparison as busybox's ash cannot deal with
floats in $(())

The run frequency and exact time affect the alfred announce interval, so we can
just run it every minute to supply alfred with the most up-to-date data.

+ mgmt and forward counters
+ packet in addition to byte counters for everything

After a lenghty discussion, we settled on absolute vs. relative values.
Main reasons:

* stateless implementation on node possible
* convertable to relative values by differentiaion on receiver
* missed transmissions only decrease granularity, whereas relative
  values would introduce wrong numbers on integration if values are
  missed

gluon-mesh-batman-adv should not be used without firewall to prevent forwarding
of packets from the mesh to the wan interface.

For some reason, the firewall package won't work at all without
kmod-ipt-nathelper.

Better configure these properly.

location is object with latitude and longitude
added:
* firmware
* autoupdater status
* hardware model
* primary mac address
* mesh IPv6 addresses

* Merge gluon-alfred-ffmap into gluon-alfred
* Use gluon-crond instead of alfred's "facter" mechanism based on the broken busybox crond

Makes manifest.sample use the model instead of the board name as that is
what the script actually expects. Also, a sample signature is added.

Recently the autoupdater contained a case statement to distinguish
between TP-Link WDR3600 and TP-Link WDR4300. This was left over from
previous development versions of autoupdater that relied on the board
name instead of the model. It is thus no longer needed and be removed
safely.

Now that haveged starts before the config mode, there is no need to explicity
depend on it; instead it is just used when specified in the site configuration.