Add toctrees to pages in the docs that did not have them.

docsite/latest/rst/YAMLSyntax.rst

 YAML Syntax
 ===========
 
+.. contents::
+   :depth: 2
+
 This page provides a basic overview of correct YAML syntax, which is how Ansible
 playbooks (our configuration management language) are expressed.  
 

docsite/latest/rst/developing_inventory.rst

 Developing Dynamic Inventory Sources
 ====================================
 
+.. contents:: `Table of contents`
+   :depth: 2
+
 As described in `intro_inventory_dynamic`, ansible can pull inventory information from dynamic sources, including cloud sources.
 
 How do we write a new one?

docsite/latest/rst/developing_plugins.rst

 Developing Plugins
 ==================
 
+.. contents::
+   :depth: 2
+
 Ansible is pluggable in a lot of other ways seperate from inventory scripts and callbacks.  Many of these features are there to cover
 fringe use cases and are infrequently needed, and others are pluggable simply because they are there to implement core features
 in ansible and were most convient to be made pluggable.

docsite/latest/rst/glossary.rst

 Glossary
 ========
 
+.. contents::
+   :depth: 2
+
 The following is a list (and re-explanation) of term definitions used elsewhere in the Ansible documentation.
 
 Consult the documentation home page for the full documentation and to see the terms in context, but this should be a good resource

docsite/latest/rst/intro_dynamic_inventory.rst

@@ -14,6 +14,10 @@ Ansible easily supports all of these options via an external inventory system.
 
 For information about writing your own, see :doc:`developing_inventory`.
 
+.. contents::
+   :depth: 2
+
+
 .. _cobbler_example:
 
 Example: The Cobbler External Inventory Script

docsite/latest/rst/intro_patterns.rst

 .. _patterns:
 
+.. contents::
+   :depth: 2
+
 Patterns
 ++++++++
 

docsite/latest/rst/playbooks_acceleration.rst

 Accelerated Mode
 ================
 
+.. contents::
+   :depth: 2
+
 .. versionadded:: 1.3
 
 While SSH using the ControlPersist feature is quite fast and scalable, there is a certain amount of overhead involved in

docsite/latest/rst/playbooks_async.rst

 Asynchronous Actions and Polling
 ================================
 
+.. contents::
+   :depth: 2
+
 By default tasks in playbooks block, meaning the connections stay open
 until the task is done on each node.  This may not always be desirable, or you may
 be running operations that take longer than the SSH timeout.

docsite/latest/rst/playbooks_checkmode.rst

 Check Mode ("Dry Run")
 ======================
 
+.. contents::
+   :depth: 2
+
 .. versionadded:: 1.1
 
 When ansible-playbook is executed with --check it will not make any changes on remote systems.  Instead, any module

docsite/latest/rst/playbooks_conditionals.rst

 Conditionals
 ============
 
+.. contents::
+   :depth: 2
+
 Often the result of a play may depend on the value of a variable, fact (something learned about the remote system), 
 or previous task result.  In some cases, the values of variables may depend on other variables.  
 Further, additional groups can be created to manage hosts based on

docsite/latest/rst/playbooks_delegation.rst

 Delegation, Rolling Updates, and Local Actions
 ==============================================
 
+.. contents::
+   :depth: 2
+
 Being designed for multi-tier deployments since the beginning, Ansible is great at doing things on one host on behalf of another, or doing local steps with reference to some remote hosts.
 
 This in particular this is very applicable when setting up continuous deployment infrastructure or zero downtime rolling updates, where you might be talking with load balancers or monitoring systems.

docsite/latest/rst/playbooks_environment.rst

 Setting the Environment (and Working With Proxies)
 ==================================================
 
+.. contents::
+   :depth: 2
+
 .. versionadded:: 1.1
 
 It is quite possible that you may need to get package updates through a proxy, or even get some package

docsite/latest/rst/playbooks_error_handling.rst

 Error Handling In Playbooks
 ===========================
 
+.. contents::
+   :depth: 2
+
 Ansible normally has defaults that make sure to check the return codes of commands and modules and
 it fails fast -- forcing an error to be dealt with unless you decide otherwise.
 y

docsite/latest/rst/playbooks_lookups.rst

 Using Lookups
 =============
 
+.. contents::
+   :depth: 2
+
 Lookup plugins allow access of data in Ansible from outside sources.  This can include the filesystem
 but also external datastores.  These values are then made available using the standard templating system
 in Ansible, and are typically used to load variables or templates with information from those systems.

docsite/latest/rst/playbooks_loops.rst

 Loops
 =====
 
+.. contents::
+   :depth: 2
+
 All about how to use loops in playbooks.
 
 .. _standard_loops:

docsite/latest/rst/playbooks_prompts.rst

 Prompts
 =======
 
+.. contents::
+   :depth: 2
+
 You may wish to prompt the user for certain input, and can
 do so with the similarly named 'vars_prompt' section.  
 

docsite/latest/rst/playbooks_tags.rst

 Tags
 ====
 
+.. contents::
+   :depth: 2
+
 If you have a large playbook it may become useful to be able to run a
 specific part of the configuration without running the whole playbook.