Fact Caching Revisited

Discussed initially on the project mailing list here: (https://groups.google.com/d/topic/ansible-project/bMWWRPxRQqg/discussion). Also discussed at length in other pulls and mailing list topics:

* [Fact caching (work in progress) infrastructure now on development branch](https://groups.google.com/d/topic/ansible-devel/aC-BjeBTMho/discussion)
* [Pull Request #5534](https://github.com/ansible/ansible/pull/5534)

Reiterating some bits for posterity:

1. Only SETUP_CACHE is leveraging caching backends. VARS_CACHE is untouched as I'm not quite sure I understand the use-case behind caching play variables between playbook executions.
2. Caching backends have a base class they should extend to ensure the API is properly implemented. All the heavy lifting is done by each caching backend.
3. Given the existing usage of SETUP_CACHE (eg: dictionary based access), caching backends must be able to return the keys that are being held in cache. There are various ways of doing that can be seen in the diff. Redis is perhaps the most interesting and optimal since it allows usage of sorted sets.
4. All unit tests pass and the sample playbooks noted as issues in the previous threads are not present. I haven't had time recently to do so, but I'll work on running the integration tests as well.

As I mentioned on the mailing list, I think redis (and probably memcached) would handle large-scale use-cases fine, but other potential backends (and probably the *file* backend I've written as well, it flushes writes to disk far to frequently) may not. If someone could advise on how best to set up a testing harness to run this against a large quantity of hosts, I would be happy to do so.

Finally, the commits will be squashed or reworded before merging to fit commit guidelines. The diff should also be viewed ignoring whitespace ([as so](https://github.com/joshdrake/ansible/compare/feature/fact_caching?expand=1&w=1)), but I can fix that immediately if needed.