Module debug to assist users in understanding Ansible

Indicate errors with exit code.

Allow user-specified $ansible_managed string

Module vsphere_facts to add facts from a VMWare vSphere guest

This hopefully fixes the documentation for the fail module

Module hpilo_facts to add facts from HP iLO interfaces

This module gathers facts from a VMWare vSphere guest by querying vSphere. The facts include OS, network info (vlan, macaddress) and system info (cpu, memory, uuid) information. Useful information for provisioning and management.

This module gathers facts from the hardware interface by querying HP iLO. The facts include network info (vlan, macaddress) and system info (cpu, memory, uuid) information. Useful information for provisioning and management.

This module was previously named ilo_facts and mentioned in #1080, #1085, #1125 and #1217.

Fix variable injection in pause module args. Closes #1209

After helping someone on IRC he was interested to have this debug module in upstream. This module simply 'prints' a message, and can be ordered to fail if needed. It helps to troubleshoot or understand inventory/facts issues and/or experiment with statements and conditions using only_if.

Here is a small example playbook:

```yaml
- hosts: all
  tasks:
  - local_action: debug msg="System $inventory_hostname has uuid ${ansible_product_uuid}"
  - local_action: debug msg="System $inventory_hostname lacks a gateway" fail=yes
    only_if: "is_unset('$ansible_default_ipv4.gateway')"
  - local_action: debug msg="System $inventory_hostname has gateway ${ansible_default_ipv4.gateway}"
    only_if: "is_set('$ansible_default_ipv4.gateway')"
```

outputting:
```
[root@moria ansible]# ansible-playbook -v -l localhost:x220 test6.yml

PLAY [all] *********************

GATHERING FACTS *********************
ok: [localhost]
ok: [x220]

TASK: [debug msg="System $inventory_hostname has uuid $ansible_product_uuid"] *********************
ok: [localhost] => {"msg": "System localhost has uuid d125a48c-364f-4e65-b225-fed42ed61fac"}
ok: [x220] => {"msg": "System x220 has uuid d125a48c-364f-4e65-b225-fed42ed61fac"}

TASK: [debug msg="System $inventory_hostname lacks a gateway" fail=yes] *********************
failed: [localhost] => {"failed": true, "msg": "System localhost lacks a gateway", "rc": 1}
ok: [x220] => {"msg": "System x220 has gateway 192.168.1.1"}

PLAY RECAP *********************
localhost                      : ok=2    changed=0    unreachable=0    failed=1
x220                           : ok=3    changed=0    unreachable=0    failed=0

```

I had some other plans for the module, like displaying host inventory and complete inventory to help understand inventory and facts modules, but that would require an action-plugin for transfering inventory information etc... And I am not sure this is wanted/best done in a module.

Library functions and modules should be in the 3 man page section. Also ...

Library functions and modules should be in the 3 man page section. Also the files should end in '.3'

Call os.path.expanduser in the creates= and removes= section of the command module so ~/ and the like works.

A fail module in order to fail execution on certain conditions

Make fatal errors red

Make ignored/skipped different from changed

Fix gather_facts assumption that SETUP_CACHE for a host is empty

Abort a play at the start when no hosts matches, or no hosts are remaining

We now check explicitely for 'module_setup' in the SETUP_CACHE in order to avoid skipping setup because SETUP_CACHE was populated some other way. Other modules can implement the same mechanism to test if they've already run.

This closes #1206.

Since a skipped/ignored action is _very_ different from actual changes to a system, it always bothered me that  it was not easily distinguishable when skimming the output. This change makes ignore/skip a different color, and I chose cyan. Contemplated using dark-gray/blue, but prefered something that is readable with most terminal colors.

In some cases you may want to deliberately fail the execution of a playbook. In our provisioning workflow we want to have safeguards in place to avoid provisioning systems that are already in production. Since we reboot physical and virtual systems, it is mandatory we take all the precautions to prevent accidental provisioning.

So in our use-case we have the following at the very start of the provisioning playbook:

    ### Safeguard to protect production systems
    - local_action: fail msg="System is not ready to be staged according to CMDB"
      only_if: "'$cmdb_status' != 'to-be-staged'"

and we repeat the same task in the (separate included) play that takes care of (re)booting the system using our own boot-media, so that it cannot be accidentally separately run by someone.

This change makes a distinction between no_hosts_matched and no_hosts_remaining.

In both cases we do not start facts-gathering, or run any tasks.

In the case that there are no more hosts remaining, we abort running tasks and abort the playbook.

I also cleaned up the leftovers from the previous patchsets, as these are no longer required.

This closes #1187.

Example playbook:

```yaml
---
- hosts: emptygroup
  tasks:
  - action: command date
  - action: command false

- hosts: all
  gather_facts: False
  tasks:
  - action: command ls
  - action: command false
  - action: command true

- hosts: all
  tasks:
  - action: command true
  - action: command false

- hosts: all
  tasks:
  - action: command pwd
```

Only gather facts once per node per playbook run

Unless gather_facts: True is on the play

Fix for issue #1194