USE subprocess.Popen API correctly.

When collecting stdout/stderr *and* feeding data into a Popen instance,
communicate() must be used to avoid a known deadlocking scenario
when data sizes cross PIPE_BUF (which can be as small as 512, although should
be much larger in practice on linux).
For defaults that are integers, enforce it for config supplied values.

If a user supplies a string in the config (rather than an int), the code
should fix that- or blow up immediately- rather than allowing that value to
work it's way down and break w/in the connection object; when that happens,
the actual error is opaque and requires pdb.set_trace() to run down.
Fix/Re-enable broken tests from 8d0487
Fix template utils to stop ignoring missing filters.

The fix here I'm not particularly happy with, but the template innards are
a bit tricky to deal with- unification would be beneficial for that code.

Regardless, previously the following would invalidly not fail in the face
of a missing filter:

- hosts: all
  tasks:
  - debug: msg="missing filter is not puking: {{ ansible_inventory_hostname|missing_filter }}"

The underlying exception for this is now caught and reported upwards, rather than
the previous opaque suppression that was going on.
Allow TemplateSyntaxErrors to propagate.

This means things like:
- set_fact: foon="{% set fact blah={} %}{{blah}}"
Now properly fails, rather than just being returned from template_from_string raw.
Post render returned data from actions.

For the set_fact action, the passed in data is directly fed back
into (effectively) host vars- without enforced rendering (meaning
undefined vars slide past) since enforcement doesn't occur for module_args.

That is a problematic API, but is suppressed via the overall better behaviour
of rendering any returned content in full.  This ensures that if an action
is being special and returning a jinja2 evaluation, the host var results
hold the rendering at that moment (rather than down the line when vars
may be missing), and has the benefit of addressing the set_fact scenario.

Literally, the following was previously valid while undefined vars were
disallowed:

- hosts: all
  tasks:
  - set: my_data="{{ undefined_var }}"
  - debug: msg="my_data is {{my_data}}" # result is {{ undefined_var }}

Now, that is an error at the time of the set_fact.
Tweak with_items error message to be more useful.

Being told "with_items only takes a list" is good; being told what
it was actually given that /was not a list/ is better since it makes debugging
variable flow in a playbook simpler (in particular, when ansible
skipped rendering of a target due to resolution failure).
Convert type checking to use isinstance.

Some of these conversions are obvious; using `isinstance(value, basestring)`
instead of `type(value) == str or type(value) == unicode`.  Others are more
subtle- dictionaries in particular.  The code doesn't actually care if it's
a dictionary or mapping like; allowing for custom mappings allows _jinja2_vars
(an internal mapping used for templating) to fully proxy any embedded dictionaries,
lists, etc, *cleanly* and fully.

Note; the conversion was generally done in place, with minimal optimization to
the surrounding code.  There are multiple spots where there is redundant/duplicate
code that could be replaced with a helper function- this is working towards that
although not required for this particular feature series thus left to be sorted
in parallel.
Make builtin plugins care less about a dict, more about mapping. rewrite this message later
initial work to fix argument passing for rendered values.

The following is fixed via this:

- set_fact: monkeys='{{ {1:2, 3:4} }}'
- debug: msg="item is {{item}}"
  with_items: monkeys.keys()
enforce do_eval for template actions /always/; it's never desirable to not have eval