The user will already have it's /etc/salt/minion file, so it doesn't need all this info, and it makes easier to know what has been generated and what not

Salt writes it's schedule file to /etc/salt/{minion,master}.d/_schedule.conf

We don't want to stomp all over Salt's files, but we do want a pristine
starting point to lay down our managed config. So we use clean: True on the
file.recurse call, but we tell it to ignore files that start with an _

We have to rename the current config file (_defaults.conf) because it will be
ignored by the rule that ignores Salt's _* config files.

This also means we need to clean up old config files (_defaults.conf) and
restart the service if we cleaned it up.

This will fix #39

And it will be backwards compatible with the current pillar configuration.

This is only needed for salt versions older than 2014.7 that do not
define the global "salt" variable in such context.

Most include do not expect salt to be something else than the usual salt
variable giving access to all the salt modules. Instead we use cfg_salt.
And for consistency we rename the master/minion variables to
cfg_master/cfg_minion too.

In Python 3, dict.items() is already an iterator while dict.iteritems() no
longer exits. In Python 2, dict.items() is not an iterator but it works
and the small performance hit doesn't really matter for the salt config
pillar data which is really small.

This state downloads formulas from git repositories and ensures
that they are recorded in the file_roots setting.

better newlines with iterations.

This will make the _defaults.conf file for master and minion
better by removing some empty lines in some code blocks

Updated gitfs jinja, to mirror master file

Gitfs for the minion is possible with salt 2014.7
Updated config _defaults.conf and pillar with example
Tested it on Archlinux with salt-call --local state.highstate

This allows users to easily add configuration settings that the formula
doesn't yet provide, without having to modify the existing templates.