We should have designed this so that post-validate and the rest of the
code here assigned semantic meaning to tokens that were parsed from the
playbook.  Unfortunately, we combined that semantic meaning with the
live playbook objects that are used by the rest of the program.  So in
post_validate we can get information that may not have come from the
playbook.

This is important because all playbook strings are text strings.  But
strings from other parts of the code may be byte strings instead.  So we
need to throw an error if we cannot convert the byte string into a text
string.  If we don't do that, we would silently mangle the string in the
convdersion and pass it on.  That would cause issues later on, for
instance, passwords that don't work with ssh or become.

Additionally, add a comment that to_text() is really here to convert
from non-string types into text.  For instance, from int and float.
If we get to the point where we are only dealing with text strings at
this point, we will still have to keep the to_text() to convert other
types.

With regular jinja,
* ascii bytes will get mangled on Python3 (text: "b'test'")
* nonascii bytes will cause a traceback in Python2

With NativeTypes jinja:
* non-ascii bytes will cause a traceback in jinja2 if it's mixed with
  text type on Python2
* any bytes will be mangled if they're mixed with text strings on
  Python3

Become and ssh pass can be read in from a password prompt.  When that
happens, we get a byte string.  Just like vault passwords, we want these
password prompts to remain byte strings all the way through the code so
that we don't lose any information from the user.

This way we can tell which scenario failed and test all three scenarios
even if one of the early ones failed.