Fix formatting of set_fact for ansible_become_pass

[fullyint]

This PR fixes a problem that causes Incorrect sudo password under specific circumstances:

• Ansible 2.2.1.0
• server.yml (not deploy.yml)
• sshd_permit_root_login: false
  so the remote-user role does a set_fact of ansible_user: "{{ admin_user }}"

I can only produce in context (not in a separate playbook for debugging). To reproduce:

  # roles/remote-user/tasks/main.yml

  - name: Load become password
    set_fact:
      ansible_become_pass: "{% for user in vault_users | default([]) if user.name == ansible_user %}{{ '{% raw %}' }}{{ user.password | default('') }}{{ '{% endraw %}' }}{% endfor %}"
+     new_var: "{% raw %}{% for user in vault_users | default([]) if user.name == ansible_user %}{{ user.password | default('') }}{% endfor %}{% endraw %}"
    when: ansible_user != 'root' and not cli_ask_become_pass | default(false) and ansible_become_pass is not defined
    no_log: true

+ - debug:
+     msg: |
+       ansible_become_pass is {{ ansible_become_pass }}
+       new_var is {{ new_var }}

Yields:

# Ansible 2.2.0.0
TASK [remote-user : debug] *************************************
ansible_become_pass is exa{{mple_password
new_var is exa{{mple_password

# Ansible 2.2.1.0
TASK [remote-user : debug] *************************************
ansible_become_pass is {% raw %}exa{{mple_password{% endraw %}     <--  Here's the problem
new_var is exa{{mple_password

It appears that with Ansible 2.2.1.0, ansible_become_pass is being submitted to the server as
{% raw %}exa{{mple_password{% endraw %} which is an Incorrect sudo password.

This PR makes Trellis submit the correct value of new_var (no {% raw %} tags submitted to server).

---

This PR moves the {% raw %} wrapper to the outer edges of the ansible_become_pass definition. In a group_vars context, that would cause the wrapper's contents to no longer be templated. But this does not hold true in the set_fact context.

Here's my best guess at how to articulate the contrast:

• The group_vars context is a "load up the YAML" context. A {% raw %} wrapper appearing in here prevents the wrapper's contents from being templated later at time of consumption.
• The set_fact task context has an initial phase of "consuming" the variables present, then switches into a "load up the YAML" phase when it loads up the facts. A {% raw %} wrapper appearing in the task context seems irrelevant for the duration of the task's initial "consuming" phase. For that moment, the {% raw %} string is just a meaningless string, not a jinja control structure, so the vars among the wrapper's contents are consumed/templated first, before anything else.