README: mention how one could reuse nagios resources with their own logic

Some people might want to inject their own logic before including nagios
resources. We can explain that since the nagios resources are in their
own part of the manifests, they can shortcut the module's automatic
handling of it, and call it manually from their own manifests.

Previous to this commit, when a stunnel::service definition was removed, the
/etc/stunnel/${name}.conf was left, and the stunnel remained running. Also, if
you changed a parameter in a stunnel::service definition, the .conf file was
changed, but the service restart may not happen properly.

This commit adds functionality to properly clean up running stunnels that are no
longer managed, and restart managed ones whose parameters have changed

Reverting "update template to get rid of older (and unreliable) helper functions, these can lead to odd results when variables are explicitly set to undef, and should be avoided"
Revert "update template to get rid of older (and unreliable) helper functions, these can lead to odd results when variables are explicitly set to undef, and should be avoided"

- everything goes into its own file -> autolookup
- order the params of the define nicer -> debugging!
- move nagios stuff to the init class -> configure module
at the very first point
- move variable version enforcing to init class ->
configure module at the very first point

rename stunnel::client to be stunnel::service to be less confusing (a
service can be a client in stunnel, and a service can act in server
mode, which would be confusing if it was called stunnel::client)

move the 'connect' variable in the template to appear right after the
'accept' variable, because that is how they typically appear in the
config files, having it show up in alphabetical order is not what
admins expect