fix wording of shell documentation

man pages have wrong chapter number

remove duplicate private-key option from manpage

Use the standard 'dest' option for target files, make 'name' an alias

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.