Major doc cleanup:

- Reformat source so it's wrapped.
- Standardise markup.
- Center images.
- Restructure in various places to improve the indexing.
- Remove duplicated Query Tool toolbar descriptions.
- Ensure the structure works in both HTML and LaTeX.

docs/en_US/submitting_patches.rst

@@ -14,7 +14,9 @@ writing code that may later be rejected.
 You should always develop patches against a checkout of the source code from the
 GIT source code repository, and not a release tarball. This ensures that you're 
 working with the latest code on the branch and makes it easier to generate
-patches correctly. You can checkout the source code with a command like::
+patches correctly. You can checkout the source code with a command like:
+
+.. code-block:: bash
 
     $ git clone git://git.postgresql.org/git/pgadmin4.git
     
@@ -22,19 +24,25 @@ Once you've made the changes you wish to make, commit them to a private
 development branch in your local repository. Then create a patch containing the
 changes in your development branch against the upstream branch on which your 
 work is based. For example, if your current branch contains your changes, you
-might run::
+might run:
+
+.. code-block:: bash
 
     $ git diff origin/master > my_cool_feature.diff
 
 to create a patch between your development branch and the public master branch.
 
-You can also create patches directly from the development tree, for example::
+You can also create patches directly from the development tree, for example:
+
+.. code-block:: bash
 
     $ git diff > my_cool_feature.diff
 
 If you are adding new files, you may need to stage them for commit, and then
 create your patch against the staging area. If any of the files are binary,
-for example, images, you will need to use the *--binary* option::
+for example, images, you will need to use the *--binary* option:
+
+.. code-block:: bash
 
     $ git add file1.py file2.py images/image1.png [...]
     $ git diff --cached --binary > my_cool_feature.diff