Basic framework for class mappings

Each node's classes are now pre-initialised depending on the
classes_mapping key in the config file, e.g.:

  class_mappings:
    '*': default
    /^local/:
      - local

This will cause all nodes to get the 'default' class before anything
else, and it will cause all nodes whose name start with "local" to get
assigned the 'local' class.

Signed-off-by: martin f. krafft <madduck@madduck.net>
Document the class mappings features

Signed-off-by: martin f. krafft <madduck@madduck.net>
Change to using a list of mappings to maintain order

Signed-off-by: martin f. krafft <madduck@madduck.net>
Enable interpolation/backreferences in regexp-class-mappings

Signed-off-by: martin f. krafft <madduck@madduck.net>
Add note about escaping slashes in regexp

Signed-off-by: martin f. krafft <madduck@madduck.net>
Document class mappings in changelog

Signed-off-by: martin f. krafft <madduck@madduck.net>
Match class mappings against entity name incl. subdir

If a node is defined in a subdirectory, then match class mappings
against the entire (relative) path of the node, including its
subdirectory.

For instance, you might have your nodes arranged in subdirectories
according to the datacentre that they are in:

  - zurich/host1.example.ch
  - zurich/host2.example.ch
  - munich/host1.example.de
  - munich/host2.example.de

A class mapping such as

  /^([^\/]+)\// hosted-in-\\1

would now automatically assign the hosted-in-zurich and hosted-in-munich
classes to the hosts, according to which subdirectory their (yaml_fs)
files reside in.

The information is transported in the so-called entity name, so other
storage backends can also introduce such "tags", they need not be
related to a filesystem path.

Signed-off-by: martin f. krafft <madduck@madduck.net>
Prepare release 1.2

Signed-off-by: martin f. krafft <madduck@madduck.net>