By not executing all scripts from gluon.announce themselves, both should
be considerably faster and lighter on RAM usage.

This adds a new announce.d datum "neighbours" (alfred 160) containing
information about mesh neighbours. It's intended to be an replacement
for batadv-vis.

In addition to the data already provided by batadv-vis it'll also
provide information about direct wifi neighbours.

Unlike batadv-vis, no data about clients is transmitted.

Sample data:

    {
      "wifi": {
        "90:f6:52:82:06:02": {
          "neighbours": {
            "f8:d1:11:2c:a7:d2": {
              "noise": -95,
              "inactive": 0,
              "signal": 0
            },
            "96:f6:52:ff:cd:6f": {
              "noise": -95,
              "inactive": 0,
              "signal": -37
            }
          }
        }
      },
      "batadv": {
        "90:f6:52:82:06:02": {
          "neighbours": {
            "96:f6:52:ff:cd:6f": {
              "lastseen": 2.8500000000000001,
              "tq": 177
            }
          }
        },
        "90:f6:52:82:06:03": {
          "neighbours": {
            "f8:d1:11:2c:a7:d3": {
              "lastseen": 2.3500000000000001,
              "tq": 206
            }
          }
        }
      },
      "node_id": "90f652820602"
    }

Moving the scripts to a common directory not only vastly simplifies the
zzz-gluon-upgrade script, but also allows to define an ordering of such
scripts across packages.

Signed-off-by: flokli <florian@darmstadt.freifunk.net>

This should reduce memory consumption a little.

https://github.com/freifunk-gluon/gluon/issues/109#issuecomment-61681696

All announce.d scripts have been moved to /lib/gluon/announce/announce.d
The script /lib/gluon/announce/announce.lua will collect all information
and output json.

This also fixes the type of a few fields which were strings instead of numbers.

This replaces announce.sh with a lua script of (hopefully) equal
functionality. Using lua generating JSON is much faster than jshn and
allows for greater flexibility.

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

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