The 'ping' module behaves differently between Ansible 2.4 and 2.5, so the
tasks/diagnose-unpingable.yml task list didn't work in Ansible 2.4.

Instead of being postfixed with '_' followed by an identifier, OS specific files
will now be postfixed with '.' followed by an identifier.

Initially, this role would check if Python was available in the default location
of '/usr/bin/python', and would install Python 2 if it wasn't. I didn't like the
idea of installing Python 2 so I updated the role to look for a usable Python
interpreter in other standard locations, including Python 3's default location
of '/usr/bin/python3'. Then it would tell the user to set
'ansible_python_interpreter' to one of the interpreters it found. I liked this
because it gave the user the choice of how to resolve the issue. However, this
role was running all the Python finding/checking tasks for every host and that
struck me as inefficient, so I changed it.

Now, the role checks if the host is pingable. If it is not, then it runs tasks
to determine why that specific host is not pingable. It then relays that
information to the user by failing out with the fail module and a descriptive
message. Hosts that are pingable do not run these tasks.

This change forces the bootstrap tasks to fail if an executable Python
interpreter can not be found. It also doesn't install Python if it can't find an
executable interpreter anymore.