Register boolean jinja filters as jinja tests

### Summary

This Pull Request ensures that all Ansible-provided boolean Jinja2 filters are also available as Jinja2 tests. Two main changes make this possible:

1. I moved boolean-valued filters from `runner/filter_plugins/core.py` to `runner/test_plugins/core.py`.
2. In `utils/template.py`, both filters and tests are registered as Jinja2 filters. Only tests are registered as tests.

I also updated some related documentation, and did some minor refactoring in `utils/template.py` to avoid excessive repetition.

### Motivation

Many Ansible filters return boolean values, but they cannot be used in tests. For example:

```yaml
# test.yml
- hosts: localhost
  gather_facts: no
  vars:
    sample:
      - { a: hello, b: world }
      - { a: goodbye, b: world }
      - { a: foo, b: bar }
  tasks:
    - debug: var="{{ sample | rejectattr('b', 'match', 'bar') | list }}"
```

Running this (with `ansible-playbook -i localhost, -e connection=local test.yml`) results in:

    jinja2.exceptions.TemplateRuntimeError: no test named 'match'

After these commits, the output is what you probably expect:

```
ok: [localhost] => {
    "[{'a': 'hello', 'b': 'world'}, {'a': 'goodbye', 'b': 'world'}]": [
        {
            "a": "hello", 
            "b": "world"
        }, 
        {
            "a": "goodbye", 
            "b": "world"
        }
    ]
}
```

Of course, this is a trivial, silly example. Because this change also allows users to define their own test_plugins, it should allow for some interesting ways to pluck data from list variables that result from calls to other modules.

### Followup work

- In order to get the tests to pass, I hacked in an import in `filter_plugins/core.py`.
    - We could obviously move some tests, but I didn't want to do a lot of boilerplate work if no one is interested in this change, and
    - It seemed like it might be more suitable to test at a higher level (i.e., try to actually use the templates) instead of baking a specific `filter_plugin/core.py` API into the tests.
- It might be worth considering a refactor of some of the plugin loading, which has quite a bit of boilerplate (I assume this is a result of minor copy-paste-edits like I used here to add the test plugins).
I did not test build the documentation, since the Contributing docs didn't indicate to do that. I did edit carefully, though, basing everything on existing examples.